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
ACDC Grant type
ACDC Grant type

Version management

Difference between version and

At line 1 added 65 lines
!!! Overview
[Authorization Cross Domain Code 1.0] registers a new Grant Type, [{$pagename}] as the urn:ietf:params:oauth:grant-type:jwt-acdc
This is a profile of the [JWT] [Authorization] [Grant Type] defined in Sec 4 of [RFC 7523] ([JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants]).
!! [{$pagename}] processing
JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the [Authorization Server]. However, if client credentials are present in the request, the authorization server [MUST] validate them.
The cnf element MUST be present in the JWT. The default confirmation method is PKCE. Other Proof of possession methods may be defined as extensions, but are out of scope for this document.
The pkce element is present in the [JWT], the AS must require the code_verifyer to be present in the request and validate it according to the PKCE [I-D.ietf-oauth-spop] specification.
If the JWT is not valid, or the current time is not within the token's valid time window for use, the authorization server constructs an error response as defined in [OAuth 2.0] ([RFC 6749]). The value of the "error" parameter MUST be the "invalid_grant" error code. The authorization server MAY include additional information regarding the reasons the JWT was considered invalid using the "error_description" or "error_uri" parameters.
For example: Figure 2
%%prettify
{{{
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_grant",
"error_description":"Audience validation failed"
}
}}} /%
!! ACDC Token
The ACDC [Token] is a single use security token that contains Claims about the [Authorization Grant]. The [ACDC Token] is represented as a [JSON Web Token] ([JWT]) [RFC 7519].
The [ACDC Token] is used to communicate [authorization] information between [Authorization Servers]. The user is passed as the value of sub is scoped to the iss.
The [ACDC Token] is audience restricted to a remote [Authorization Server] via the aud (audience) Claim.
The cnf claim from JWT POP communicates the [PKCE] code_challange and code_challange_method. If [code_challange_method] is not included the default is "S256". The code_challange_method "plain" __MUST NOT__ be used.
The scopes claim is an array of scopes that the [Authorization Server] has granted for this client.
The sid claim is a string identifying the user session as understood by the [Authorization Servers]. In the case of a [native application] this __SHOULD__ identify the device.
The following is a non-normative example of a [base64]url decoded [ACDC Token] with the remote [Authorization Server] as the value of aud and the [Client_id] as the value of azp (with line wraps for display purposes only):
%%prettify
{{{
{
"iss": "https://server.example.com",
"sub": "24400320",
"azp": "client-ID",
"aud": "https://server.partner.com",
"exp": 1311281970,
"iat": 1311280970,
"sid": "Work iPhone",
"cnf":{ "code_challange" : "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM",
"code_challange_method" : "S256" },
"scopes" : [ "scope1" , "scope2" ]
}
}}} /%
!! 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