!!! 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' }]