OAuth 2.0 Scopes

The purpose of OAuth 2.0 scopes is to limit the authorization granted by the user to a client.

The AS-centric AS implements this as follows:

  1. The client requests a set of scopes when starting an authorization code flow.
  2. The AS filters all scopes requested with the list of scopes the client is allowed to request.
  3. The AS presents the filtered scopes to the user during authentication.
  4. The user decides which scopes to grant through local or remote consent.
  5. The AS filters the list of granted scopes through the Granted Scopes Processor.
  6. All scopes granted are added to the resulting tokens.

Filtering of scopes

Airlock IAM supports several mechanisms to filter scopes:

  1. Dynamically registered clients may only request scopes they were registered for.
  2. If no scopes have been registered, the client (static or dynamic) may request any scope.
  3. Scopes requested by the client are filtered against:
    • Roles from various sources (user persister, SSO token, etc.)
    • Flow properties of the current authentication flow.
    • Scopes may also be transformed before being presented to the user.
  4. After scopes have been granted by the user, Scopes may once again be filtered by the AS.

Translation of scopes

Scopes are presented to the user when granting consent is required. To support human-readable scopes, two translation mechanisms are provided:

  • Server-side translation where the translations are configured on the server.
  • Client-side translations where the client will provide the translations. If the Loginapp REST UI is used, the SDK can be used to manage the client-side translations.

The Loginapp REST UI displays scopes based on the following rule:

  1. Use server-side translated scope (configuration) if present.
  2. Use client-side translated scope if present.
  3. Use technical scope name

If scopes change often, server-side translation is preferable because the deployment of new translations on clients tends to be more costly.