Share via

3.2.5.1.2.3 Processing Details

  • Article

After receiving the request, the server verifies the signature of the request and also verifies that the request_nonce is a nonce value previously issued by the server as defined in section 3.2.5.1.1. The server SHOULD also verify that the nonce was issued recently.<5> If the signature or nonce are invalid, the server returns the error "invalid_grant" using the format described in [RFC6749] section 5.2.

The server then processes the request as a resource owner password credentials grant (see [RFC6749] section 4.3) using the client_id field of the request with the following modifications:

  • The server authenticates the user based on the fields of the request:

    • If the request uses username and password authentication as in section 3.2.5.1.2.1.1, the server authenticates the user as in a resource owner password credentials grant ([RFC6749] section 4.3) using the client_id, scope, and password fields of the request.

    • If the request uses user JWT authentication as in section 3.2.5.1.2.1.2, the server processes the request as follows:

      1. The server finds the user object in Active Directory with a user principal name ([MS-ADTS] section 5.1.1.1.1) matching the iss field of the assertion JWT.

      2. It finds the public key for the signature by finding the value of the msDS-KeyCredentialLink attribute on the user object for which the SHA-256 hash ([FIPS180-2] section 6.2.2) of the attribute value matches the kid field of the assertion JWT.

      If the kid of the authenticated device does not match the kid of the assertion JWT, the server SHOULD verify that the assertion contains the request_nonce field and that it also matches the request_nonce present in the request body (section 3.2.5.1.2.1). Otherwise, the server MUST return the "invalid_grant" error using the format described in section 5 of [RFC6749].

      Note: This behavior is supported by the operating systems specified in [MSFT-CVE-2023-35348], each with its related KB article download installed.

      3. The server then verifies the signature of the assertion JWT by using the public key that was found in the previous step.

      4. If any of the corresponding objects or values cannot be found or the signature of the assertion JWT is not valid, the server returns the "invalid_grant" error using the format described in [RFC6749] section 5.2.

    • If the request uses refresh token authentication as in section 3.2.5.1.2.1.3, the server validates the refresh token as in [RFC6749] section 6.

    • If the request uses user certificate authentication as in section 3.2.5.1.2.1.4, the server verifies the signature of the assertion JWT and authenticates the user for whom the certificate in the x5c header field was issued.

  • The server uses the response format described in section 3.2.5.1.2.2 for successful responses; error responses are returned as described in [RFC6749] section 5.2.

  • If the server requires user interaction at the authorization endpoint ([MS-OAPX] section 3.2.5.1) before processing this request (for example, to give consent or to provide additional authentication), the server returns the interaction_required error using the format described in [RFC6749] section 5.2.

  • The server does NOT issue an access token.

  • The server MUST issue a primary refresh token (in place of a normal refresh token) and include it in the refresh_token field of the response.

    Note: Primary refresh tokens are opaque to the client. The structure and content of a primary refresh token is implementation-specific. However, it must include information that allows the server to find the associated user in the identity data store that is being used (for example, Active Directory).

  • The server MUST include an ID token [OIDCCore] in the id_token field response.

The server finds the msDS-Device object in Active Directory that has an altSecurityIdentities value matching the value of the x5c parameter of the request header. The server then populates the session_key_jwe field of the response by creating a session key and encrypting it by following the process in [RFC7516] section 5.1 and by using the session transport key found in the msDS-KeyCredentialLink attribute of the previously located msDS-Device object.