[OPENAM-6534] Update OAuth2 tokeninfo endpoint to be realm-independent Created: 05/Aug/15  Updated: 20/Nov/16  Resolved: 12/Aug/15

Status: Resolved
Project: OpenAM
Component/s: oauth2
Affects Version/s: 12.0.1
Fix Version/s: 12.0.2, 12.0.3, 13.0.0

Type: New Feature Priority: Major
Reporter: Nathalie Hoet Assignee: Peter Major [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: CustomerRFE, EDISON, release-notes, test-candidate
Remaining Estimate: 0h
Time Spent: 12h
Original Estimate: 0h

Target Version/s:
Sprint: Sustaining Sprint 10
Support Ticket IDs:
Verified Version/s:

 Description   

As of now (last stable release is 12.0.1), if an access_token is obtained from realmB, a request to tokeninfo endpoint must contain a reference to the correct realm realmB - either through DNS Alias or parameter - to succeed.

For example the following is not successful:

$ curl --request POST --data "client_secret=clientsecret&client_id=testclient&username=testuser&password=userpassword&grant_type=password&scope=email" http://openam.example.com:8080/openam/oauth2/access_token?realm=/testrealm

{"scope":"email","expires_in":59,"token_type":"Bearer","access_token":"ca79234e-0a4f-4abb-85f3-6de4e538ee8f"}

$ curl -k 'http://openam.example.com:8080/openam/oauth2/tokeninfo?access_token=ca79234e-0a4f-4abb-85f3-6de4e538ee8f'

{"error":"invalid_request","error_description":"Access Token not valid"}

This happens because the second request does not contain the realm and a check is performed when validating the token.

There exists scenarios for which it would make sense to give access to information on an access_token from any realm and it would be good to have a configuration that allows such behaviour.

If implemented, the related documentation should highlight which type of environment can safely disable strict realm checking and which environment would be at risk.



 Comments   
Comment by Peter Major [X] (Inactive) [ 12/Aug/15 ]

Resolved with R15106 and R15108

Comment by Quentin CASTEL [X] (Inactive) [ 20/Aug/15 ]

Would be nice to have some clarification of what the bug fix does exactly. From the diff, it seems to be more about where the token can be used. This fix doesn't really make the tokeninfo endpoint realm-independent (as the title suggests).

Comment by Nemanja Lukic [ 02/Oct/15 ]

Verified in: OpenAM 12.0.2 Build 15797 (2015-September-21 17:41)

Comment by Nemanja Lukic [ 26/Apr/16 ]

Steps to reproduce:

  1. create realm testrealm
  2. create Oauth2 provider in the new realm
  3. create OpenID client in the new realm with the following characteristics
    Username testclient
    Password clientsecret
    Scope email
  4. create a test user in the realm: testuser/userpassword
  5. execute
    # curl --request POST --data "client_secret=clientsecret&client_id=testclient&username=testuser&password=userpassword&grant_type=password&scope=email" http://ft-oam.test.forgerock.com:8080/openam/oauth2/access_token?realm=/testrealm
    {"scope":"email","expires_in":59,"token_type":"Bearer","access_token":"720a93c4-2525-4673-8eb5-ca38cdcae20d"}
    
  6. use the token in the following call:
    curl -k 'http://ft-oam.test.forgerock.com:8080/openam/oauth2/tokeninfo?access_token=720a93c4-2525-4673-8eb5-ca38cdcae20d'
    {"scope":["email"],"grant_type":"password","email":"","realm":"/testrealm","token_type":"Bearer","expires_in":12,"access_token":"720a93c4-2525-4673-8eb5-ca38cdcae20d"}
    
Comment by Nemanja Lukic [ 26/Apr/16 ]

Verified in: 12.0.3-RC2

Generated at Mon Oct 19 16:07:58 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.