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.

More Information#

There might be more information for this subject on one of the following:

• ACDC Grant type
• ACDC Token