OAuth 2.0 consent

The OAuth 2.0 Authorization Code Grant involves getting a user confirmation – a so-called consent - before granting an access token to the OAuth client.

The following table explains the major differences between local and remote consent:


 

Local consent

Remote consent

Supported scopes

The local AS enforces which scopes are supported.

A remote consent server will enforce which scopes are supported.

IAM can filter this list of scopes.

Service

Consent management is implemented entirely in Airlock IAM.

A third-party service implements remote consent.

Authorization code grant

The OAuth 2.0 client must request a scope that passes validation by the AS.

The remote consent server returns a list of scopes and Airlock IAM accepts this list as correct.

Client credentials grant

The OAuth 2.0 client requests the scopes. Airlock IAM verifies that the scopes are white-listed.

Remote consent is not required for the client credentials grant.

OAuth 2.0 AS with local consent

  • When using the local consent concept, the authorization server controls which scopes are presented to the user by configuring filters that limit the scopes.

OAuth 2.0 AS with remote consent

  • When using the remote consent concept, Airlock IAM does not know about the scopes granted by the remote consent application.
  • Airlock IAM accepts and uses the scopes as reported by the remote consent application.

Learn more about remote consent in chapter Remote consent applications with OAuth.

OAuth 2.0 Client (request scopes)

The scopes received from a remote OAuth 2.0 AS are not considered in Airlock IAM.

Instead, to obtain roles, the client must:

  • OAuth 2.0: Query a resource on the AS/Resource Server to get a list of roles.
  • OpenID Connect: 
    • Query a resource
    • or obtain the roles from a value of the ID Token

  • Learn more about client configuration in chapter Configuration of Airlock IAM as OAuth 2.0 Client.