Overview#
Authorization Cross Domain Code 1.0 (ACDC Grant type) and Internet Draft which defines a profile of the OpenID Connect Core 1.0 (OpenID Connect Core 1.0) specification that stipulates how a OAuth Client can obtain single-use tokens that can be exchanged for Access Token & Refresh Tokens at federated token_endpoints.More and more applications, both enterprise on-prem and cloud-based, are accessed through REST APIs in addition to, or instead of, browser-based access. Mobile clients will be a key consumer of such APIs. Native installed applications (e.g for iOS , Android, BlackBerry, etc devices) offer an important alternative to web or browser-based applications. Both models have their pros/cons.
OAuth 2.0 is an authentication & authorization framework for such REST APIs. Critically,OAuth 2.0 is explicitly designed to support the variety of different client types that will be accessing REST APIs - both applications running on web servers within the enterprise calling out to the cloud/partners etc, as well as applications running on mobile phones belonging to employees and customers. OAuth supports this variety of client types by defining multiple mechanisms for 'getting a token', the different mechanisms acknowledging the constraints of particular client types.
For accessing protected resources behind an API using OAuth for authentication, the mobile application requires an access token - this to be presented on the HTTP calls to the API.
The high-level sequence by which the client obtains and uses an access token is:
- Get the User authenticated at the corresponding Authorization Server (AS)
- (OPT) Get the AS to obtain the User's consent for the client's access of the API
- Accept the token(s) delivered back by the AS
- Attach the access token to REST API calls:definition text
The ACDC model is shown below
+-------------+ | Device | | +--------+ | +-----------+ | | |-------- Login & Authorization (1)--------->| | | | | | | | | | App |<------ ACDC for app- (2)-------------------| | | | | | | AS 1 | | | | | | | | | | | | | | | | | | | | | | | +-----------+ | | | | | | | | | | | | +-----------+ | | |---- Request Secondary tokens for app (3)-->| | | | | | | AS 2 | | | |<-------Secondary Tokens for apps (4)-------| | | | | | +-----------+ | | | | /\ /\ | | | | | | | | | | Validate tokens (6) | | | | | | | | | | +---------+ | | | -|--------- API Call with token (5)-------> | RS2 | | +--------+ | +---------+ +-------------+Figure 1
- The OAuth Client requests a ACDC grant using the acdc responce_type.
- The OAuth Client also sends a PKCE challenge.
- The OAuth Client may also include the Audience parameter (aud), to indicate the token_endpoint it intends to exchange the acdc at.
- The ACDC token is returned to the OAuth Client in the acdc parameter.
- The OAuth Client exchanges the acdc and PKCE verifier at the token_endpoint identified by the aud parameter from (1).
- The OAuth Client receives access token and optional refresh token from AS2.
- The OAuth Client accesses the resource server.
Note: the token validation of Step 6 may require a call to the issuing AS (as shown) or may be achieved locally via a digital Signature verification.
