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

OAuth2 Scriptable/policy-driven Scopes


    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 13.0.0
    • Fix Version/s: 6.0.0
    • Component/s: oauth2
    • Labels:
    • Support Ticket IDs:


      Scopes are often used to determine the permissions that the token is granted. Currently the Scopes returned in a token at grant stage are fixed (based on what was requested and what is defined in the client settings).
      A new feature should be added that allows scopes to be returned based on a flexible set of conditions applied to requesting subject. This might be, for example, group membership, time of day, or any other existing policy condition.

      The OAuth2 spec (https://tools.ietf.org/html/rfc6749) allows an AS to return a set of scopes that is different to the set that was requested, so this enhancement remains inside the spec.

      Business Case
      Authorization and policy management are key components of OpenAM and extending its use in a standards enabled way, provides a powerful function within OAuth2 deployments.

      Exit Criteria
      A client representing two different user requests for scopes, would return two different subsets based on a policy evaluation.

      Eg Alice requests scopes=read, delete and Bob requests scope=read, delete. Alice receives scope=read and Bob receives scope=read,delete. This is based on a policy condition that, for scope=delete, only evaluates to true when the user is a member of the "Admin" LDAP group (or variant of that condition).

      A practical consumer facing example could be:
      It is possible to implement scenarios such as 'paid-for' services, using scopes as permissions - as defined by the spec. i.e. an API protected by OAuth2 returns 'address' data if the user has paid for this premium service. Otherwise, address data is omitted. The API would check for the presence of the 'premium' scope in the access_token to grant/deny access.
      In order for the token to include the scope, the AS (OpenAM) would check the policy at token grant stage to include/exclude the scope based on the permissions (e.g attributes/memberships etc) of the user.

      An extension use case would be to also implement policy evaluation during the refresh_token to access_token exchange, to make sure the condition that evaluated to true during the initial issuance, was still valid.


          Issue Links



              • Assignee:
                FatBloke Andy Hall
                andrew.potter Andrew Potter
              • Votes:
                3 Vote for this issue
                13 Start watching this issue


                • Created: