This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Authorization Cross Domain Code 1.0
Authorization Cross Domain Code 1.0

Version management

Difference between version and

At line 1 added 64 lines
!!! 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' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop