Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-15389

As an OP, AM should return an error to the RP when the authentication failed or the consent is denied by the RO

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 6.5.2.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Target Version/s:

      Description

      Bug description

      Context:

      During the authorisation code grant flow, the resource owner is invited to authenticate and authorise the request. If everything goes correctly, an authorisation code is issued to the OIDC client.

      The issue is happening on error handling from the resource owner:
      The OP (it's AM) should handle potential 4xx errors and when appropriate, return the error:

      • In the UI screen, by displaying the error to the resource owner
      • to the OIDC client via the redirect uri using the fragment. ie: redirect_uri#error_code=$errorCode&error_description=$error_description.

       

      The issue:

      When the Resource owner failed to authenticate or reject the consent, the OP should redirect the error to the OIDC client via the fragment.

      Currently, AM is returning the error to the resource owner.

       

      In different part of the spec, it says that:

       

      Unless the Redirection URI is invalid, the Authorization Server returns the Client to the Redirection URI specified in the Authorization Request with the appropriate error and state parameters.

      https://openid.net/specs/openid-connect-core-1_0.html#AuthError

      If the resource owner denies the access request or if the request
      fails for reasons other than a missing or invalid redirection URI,
      the authorization server informs the client by adding the following
      parameters to the query component of the redirection URI using the
      "application/x-www-form-urlencoded" format, per
       

      https://tools.ietf.org/html/rfc6749#section-4.1.2.1

      How to reproduce the issue

      First start by setting up a successful authorisation code grant flow

      1. First start by setting up a successful authorisation code grant flow
      2. Setup a basic tree as the default authentication service. (just a login/password tree would do the job)
      3. Once you managed to get an authorisation code return to the RP, you can consider you have the success scenario done.

      To reproduce the authentication failure handling scenario

      1. Restart the authorisation code grant flow but this time, enter a wrong password.
      Expected behaviour
      A redirection to the OIDC client with in the fragment an error code and error description, potentially something like:
      `#error_code=access_denied&error_description=Resource owner failed to authenticate`
      
      Current behaviour
      The resource owner received the authentication failure and nothing else happen
      

      To reproduce the authorisation failure handling scenario

      1. Restart the authorisation code grant flow
      2. Enter the right credential. You will be redirected to the consent page
      3. Deny the consent
      Expected behaviour
      A redirection to the OIDC client with in the fragment an error code and error description, potentially something like:
      `#error_code=access_denied&error_description=Resource owner denied the request`
      
      Current behaviour
      The resource owner received the authorisation failure and nothing else happen
      

      Standard interpretation

      It's not easy to identify which error code you should use in those error scenarios.
      The one that seems to be the closest that we can use:

      access_denied
                     The resource owner or authorization server denied the
                     request.
      

      @James suggested that, as this is a major change of behaviour, this fix should be switch in by the config.
      ie: enabled by default on a vanilla AM installation. Disabled if it's an AM upgrade.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              quentin.castel Quentin CASTEL [X] (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: