!!! Overview
[{$pagename}] ([ACDC Grant type]) and [Internet Draft] which defines a [profile|OpenID Connect Profile] of the [OpenID Connect] Core 1.0 ([OpenID Connect Core 1.0]) specification that stipulates how a [OAuth Client] can obtain [single-use token]s 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|Mobile Device] will be a key consumer of such APIs. [Native installed applications|Native application] (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 %%strike authentication &/% authorization framework for such [REST] APIs. Critically,[OAuth 2.0] is explicitly designed to support the variety of different [client types|OAuth 2.0 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|OAuth 2.0] 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|Authorization Server] (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:
[{ReferringPagesPlugin before='*' after='\n' }]