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

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:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-3) was last changed on 14-Mar-2016 18:08 by jim