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.