OAuth 2.0 consent

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.

Remote consent is implemented by a third-party service.

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 through the configuration of filters that limit the scopes.

OAuth 2.0 AS with remote consent

  • When using the remote consent concept (see Remote consent applications with OAuth), 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.

OAuth 2.0 Client (request scopes)

The scopes received from a remote OAuth 2.0 AS are not taken into account in Airlock IAM.

Instead, in order 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
  • See also Airlock IAM as client (OAuth 2.0/OIDC).