Remote consent protocol

The Remote Consent Protocol is embedded in the OAuth 2.0 Authorization Code Grant Flow and begins after the end-user has been authenticated itself in IAM.

The following parties are involved:

Party	OAuth 2 Concept	Authorization Code Flow	Remote Consent Protocol
End-User (Browser)	User-Agent
Third-Party Application	Client
Airlock IAM	Authorization Server (AS)
Remote Consent Application	-

The Remote Consent Flow (green) is embedded in the OAuth 2.0 Authorization Code Flow (blue) such that it can be executed instead of displaying the IAM's consent page.

The Remote Consent Protocol (green) is as follows:

Step	Description	Details
(1)/(2)	Standard authentication steps.	–
(3)	After the end-user has been authenticated: IAM redirects the end-user's browser to the Remote Consent Application.	With the redirect, IAM sends several HTTP GET parameters. Example Redirect URL (not URL-encoded): /ebanking/display-consent?lang=de&consent_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVC... (JWT truncated) Request parameters: `lang` – contains the two-letter language code (e.g. `en` or `de`) of the login page display language. This is the language the end-user chose to log in with. `consent_token` is an encrypted and signed JWT bearing the claims `sub` – the name of the authenticated end-user. This is an IAM-internal username and not necessarily the same as the user entered when logging in. `scope` – the scopes requested by the OAuth client (JSON array). `consent_nonce` – a nonce for this remote consent flow. `callback_uri` – the Remote Consent Application must redirect the end-user's browser to this URI after consent. `exp` – the expiry date of the registered claim following RFC7519. The token lifetime is configurable in IAM. The Remote Consent Application must not accept expired tokens. `iat` – the issue timestamp of the registered claim following RFC7519. If the issue timestamp lies in the future, the Remote Consent Application must consider the token invalid. `client_id` – the client id of the OAuth2 client.
(4)	The end-user interacts with the Remote Consent Application to give the consent: The Remote Consent Application reads and verifies the JWT "consent_token" to display the consent screen to the end-user.	–
(5)	The Remote Consent Application redirects the end-user's browser back to the callback_uri and puts an encrypted and signed JWT as GET parameter `consent_token` in the HTTP redirect.	The JWT bears the following claims: `consent_given` – true or false. Indicates whether the user gave consent or not. `scope` – The scopes accepted by the end-user (JSON array). May be empty. Must be empty if consent_given is false. `consent_nonce` – The nonce as received in the JWT `consent_token`. Example Redirect URL (not URL-encoded): /auth/oauth2/v3/confirm-consent?consent_token=eyJhbGciOiJIUzI1NiIsInR5c... (JWT truncated) Airlock IAM writes the JWT to the audit log file. If no JWT is present or the JWT cannot be validated, the OAuth 2.0 flow is aborted in Airlock IAM.
(6)	Airlock IAM verifies the JWT from the Remote Consent Application	If `consent_given` is `true` – the Authorization Code flow continues in Airlock IAM. If `consent_given` is `false` – the remote consent is aborted, and no `authorization_code` is issued.