ACDC Grant type


Authorization Cross Domain Code 1.0 registers a new Grant Type, ACDC Grant type 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).

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

HTTP/1.1 400 Bad Request
     Content-Type: application/json
     Cache-Control: no-store

      "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 base64url 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):

   "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: