[OPENAM-11070] Need OAuth2 authentication to work in Android with implied consent Created: 24/Apr/17  Updated: 27/Sep/18  Resolved: 05/Oct/17

Status: Resolved
Project: OpenAM
Component/s: XUI
Affects Version/s: 13.5.0, 14.1.1, 14.5.0
Fix Version/s: 13.5.2, 14.5.0

Type: Bug Priority: Major
Reporter: Kamal Sivanandam Assignee: Phil Ostler [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: AME, Must-Fix, TURING
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Android OS 4.1 and higher and Chrome 40 and higher.


Attachments: GIF File ActualResult.gif     PNG File ExpectedResult.png     File LoginHelper.js     File RESTLoginView.js     PNG File Sep-05-Nightly.png    
Target Version/s:
Sprint: Sprint 125 "Fu" Turing, Sprint 126 "Gauguin" Turing
Needs backport:
Yes
Support Ticket IDs:
Verified Version/s:
Needs QA verification:
Yes
Functional tests:
No
Are the reproduction steps defined?:
Yes and I used the same an in the description

 Description   

OAuth 2.0 Authentication on an Android device is fails with implied consent.

Steps to Reproduce

  1. Follow general setup from quick start guide found here: https://backstage.forgerock.com/docs/am/5.1/quick-start-guide
  2. Create a new realm called `TEST`
  3. Add a new 'OAuth2 Provider' service
    1. Enable the 'Allow clients to skip consent' option
  4. Add a new 'Oauth 2.0/OpenId Connect Client' agent, with name 'client'
    1. Add the following redirect_uri: market://details?id=com.google.android.apps.maps
    2. Add the scope 'openid'
    3. Enable the option 'Implied Consent'
  5. Add a new subject to the realm with username 'test' and password 'password'

Then to reproduce using the above config:

  1. In the chrome browser of an android device navigate to:
    1. http://openam.example.com:8080/openam/oauth2/TEST/authorize?client_id=client&response_type=code&scope=openid&redirect_uri=market://details?id=com.google.android.apps.maps
    2. http://openam.example.com:8080 should be replaced with your openam instance
  2. Login with the user added in step 5 of the config (test:password)

N.B. This can easily be tested locally with your machine and Android device on the same network, the Android device being proxied through your machine to ensure hostnames map correctly.

Expected Behaviour
You are redirected to the google maps app in the play store (See screenshot ExpectedResult.png)

Actual Behaviour
You are presented with ERR_UNKNOWN_URL_SCHEME error (See screenshot ActualResult.gif)

Workaround
Custom url scheme is working by disabling implied consent, with the additional consent screen in place redirect back to the mobile app works.

Original Description
OAuth2 for authentication on an android device is failing with implied consent.
1) Open a chrome custom tab with the OAuth2 endpoint to retrieve the authorization code
2) OpenAM redirects back to the mobile app using a custom url scheme providing the app with the authorization code as a url parameter.
3) The mobile app then sends a request to our backend which uses the authorization code to retrieve the access_token.

Step 2 is failing with the ERR_UNKNOWN_URL_SCHEME error when enabling implied consent.

Custom url scheme is working by disabling implied consent, with the additional consent screen in place redirect back to the mobile app works.



 Comments   
Comment by Andy Hall [ 26/Apr/17 ]

Kamal Sivanandam Which versions of Android/Chrome are affected?

Comment by Julian Kigwana [X] (Inactive) [ 16/May/17 ]

I'm unable to reproduce this error in Andriod 5.0.2 on my HTC One. Chrome 57.0.2987.132 using the ForgeRock authenticator app as the redirect_uri

Comment by Andy Hall [ 18/May/17 ]

Kamal Sivanandam it would be really helpful if you had a simple reproduction recipe with app.

Comment by Julian Kigwana [X] (Inactive) [ 26/May/17 ]

I'm still unable to reproduce the error using market://details?id=com.ultimatesoftware.ultipromobile using 14.5, however using 13.5 the request to open the store fails with 400 "bad_request". 

Comment by Kamal Sivanandam [ 05/Sep/17 ]

Andy Hall I have verified the behavior in master last Tuesday(08/29) and I get the same error as customer.

Comment by Phil Ostler [X] (Inactive) [ 13/Sep/17 ]

Not sure about the need to backport so marked as "Yes".

Comment by Kamal Sivanandam [ 15/Sep/17 ]

Phil Ostler [X] Customer is currently running with 13.5.0 and will be great if the fix is backported to 13.5.x

Comment by Phil Ostler [X] (Inactive) [ 15/Sep/17 ]

Kamal Sivanandam I guessed so. I marked this as "Yes" to backport, so support should pick that up from here.

Comment by Jonathan Thomas [ 05/Oct/17 ]

Fixing in 13.5.2 and  updating commons UI  13.0.10

Comment by Ľubomír Mlích [ 31/Oct/17 ]

Reproduced in OpenAM 13.5.0 Build 550cfe7d60 (2016-July-13 08:43) 
Verified in OpenAM 13.5.2-M7 Build 1d3e4900c0 (2017-October-20 09:14) 

Generated at Mon Sep 28 05:04:26 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.