invalid at_hash when access token is JWT

[Hugo Pagola]

We are using OpenId for user authentication with Authorization Code flow, response_type token id_token.
To generate an access_token as JWT the Policy #OTK Generate JWT OAuth Token is activated and also we are guided by the following page:

https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/api-management-oauth-toolkit/4-3/installation-workflow/configure-authentication/token-configuration/configure-jwt-access-tokens.html#concept.dita_3a688ef9d8162d303d6f0f85df7b25359a0700c5_customClaimJWT

It is important to indicate that no changes have been made to the Policy and you find the code that comes by default.

When a user with this type of flow is authenticated, it returns an id_token and an access_token in JWT format.
When decoding the id_token shows us the At_hash that allows us to validate the access_token:
{
"at_hash": "hgirfkCMFOsmoD4kywVRGw",
"sub": "uRg2yrU0sqQYV5U-IXjWA4YeX7Zjsr6BTzHHCKjC0O0",
"aud": "34b33311-d424-49b6-a256-b6df27904f67",
"acr": "0",
"azp": "34b33311-d424-49b6-a256-b6df27904f67",
"auth_time": 1577727723,
"iss": 

"https://magdesa.ypf.com:8443"

,
"exp": 1577814124,
"iat": 1577727724,
"nonce": "somevalue"
}

The hash of the Access_token is as follows:
Hash:CDiCxiaG3jLMHney7M6w3w

The issue we have is in the validation of the access_token since to validate the at_hash found in the id_token is compared with the hash that is obtained from the Access_token. We note that when making this comparison, the at_hash is incorrect and we cannot validate the access_token, as it results in a different hash.

To perform the Access Token validation we are guided by the following page:

https://openid.net/specs/openid-connect-core-1_0.html#ImplicitTokenValidation

For the validation it was done through two processes, the first one using an angular library that returns an exception that indicates that the at_hash is invalid and the second one was manually verified and also has the hash incorrect.

It is worth mentioning that a test was performed by generating an Access_token without the JWT format by sending the Authorization Code flow parameters, response_type token id_token.
The user is authenticated, an id_token is returned and an Access_token is validated, we extract the at_hash from the id_token and compare with the hash we obtain from the Access_token and it results in the hashes being the same.

[Kemal Ajan]

Hugo 

this question may be for a support case

[Tomohiro Kada]

I think that the hash algorithm used to create "at hast" and "c hash" is SHA256 (not HMAC SHA256). I think that "Generate ID Token" assertion is used in the policy.
This assertion generates the hash with SHA 256.  I checked out this with OTK 4.2 and it seems that we are not able to specify the hash algorithm. Need enhancement.
I have not tested with the latest OTK version.

[Hugo Pagola]

Thanks for the comment, but the issue we have is when we validate the access_token.
What we do is compare the at_hash of the id_token with the hash we get from the access_token when doing this process we observe that the hash are different.

[Tomohiro Kada]

I don't know how you calculated the "at_hash" from Access Token but I was able to create a hash string from Access Token with Python and google oauth2client library. This value is exactly the same as the value of at_hash included in ID Token.

I tested response_type=token id_token (OIDC Implicit Flow) with OTK 4.3.1 running on GW v9.4.

----
import hashlib

token_to_hash = "f8f5cadb-0901-40ec-9650-1dbcae313458" < This is the Access Token obtained from Authorization Server.

hash = hashlib.sha256(token_to_hash.encode('utf-8'))

digest = hash.digest()

digest_truncated = digest[:(len(digest)/2)]

import oauth2client

from oauth2client import _helpers

token_hash_computed = oauth2client._helpers._urlsafe_b64encode(digest_truncated)

print(token_hash_computed)
eRCpj2wcF9dD_0dWmps5Sg < This value is exactly the same as the value of at_hash included in ID Token
------

[Hugo Pagola]

Thanks for the comment, but the issue occurs when the access_token has JWT format, when you want to validate the at_hash with the hash obtained in the access_token we notice that it is not the same.
If the access token is not in JWT format as the example you indicate, the hash is validated correctly.

[Tomohiro Kada]

I think that if you use "JWT" Access Token and need validation, you can't use "at_hash". at_hash is for validation of UUID based Access Token. I I think that JWT Access Token is not in the scope of OpenID Connect Core spec. But you can reference the following draft document - "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" - https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03

In this draft spec, you can see the instructions on how we can validate the JWT (Access Token). JWT Signature validation needs to be done.
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-03#section-4

If your resource server is CA API GW, you can reference the following instruction on how JWT(Access Token) can be validated by the Gateway.
"Validate a JWT Access Token"
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/layer7-api-management/api-management-oauth-toolkit/4-3/installation-workflow/configure-authentication/token-configuration/configure-jwt-access-tokens.html

If your resource server is not CA API GW, resource server needs to extract the JOSE header from JWT.  API GW provides jwks_uri endpoint
that returns the public certificate used for JWT signature validation.  I think that "default ssl key" is used to create the signature of JWT.

[Hugo Pagola]

The at_hash is to validate the Access Token and is not just for one type of format.
The API_GATEWAY returns the at_hash value in both cases for JWT and UUID.
This at_hash should allow the validation of the Access Token. But in the case of JWT, the hash does not match.

Regarding the links to validate the JWT are valid and would be used when using the JWT to access a resource on the resource server.

In other words, the Access Token is validated first with the at_hash and then when using the JWT token to access a resource, the JWT will be validated with the previously sent links.

[Tomohiro Kada]

>But in the case of JWT, the hash does not match.
I understand what you explain. But I think product enhancement is required to achieve this.

>In other words, the Access Token is validated first with the at_hash and then when using the JWT token to access a resource,
>the JWT will be validated with the previously sent links.
For workaround, API Client is also able to validate the "JWT" Access Token with "signature"(not hash) to see if it is modified like ID Token validation with signature. There is also a possibility that ID Token is modified so OpenID Connect spec specifies that "the contents of the ID Token MUST be validated" by API Client.

https://openid.net/specs/openid-connect-core-1_0.html#ImplicitIDTValidation

[Joe Dascole]

Hugo,

The hash is of the JTI field in the JWT access token. If you decode the JWT Access Token and parse out the JTI the signature will match the hash of JTI.
If you would like I can provide a sample of this if required for your particular use case.

Regards,
Joe