at_hash not added to id_token after successful authorization

Help
, , , ,
1

I’m trying to authenticate a React Native app using the react-native-auth0 package, but I haven’t been able to get an at_hash to be returned in my id_token, regardless of the different configuration settings I’ve tweaked.

Here is the JS code I am using to initiate the request:

const auth0 = new Auth0({ domain: '<domain>', clientId: '<id>' });
const credentials = await auth0
  .auth
  .passwordRealm({
    username: '<username>',
    password: '<password>',
    scope: 'openid',
    responseType: 'id_token token',
    nonce: '<random hash>',
    realm: '<realm>',
  });

console.log(credentials.idToken);

The id_token, after I decode it at jwt.io, contains the following keys:

"nickname"
"name"
"picture"
"updated_at"
"email"
"email_verified"
"iss"
"sub"
"aud"
"iat"
"exp"

I have tried changing the scope/responseType and using different types of authentication schemes to no effect.

I’m stumped.

2

You’re using the passwordRealm method which performs an extension grant to the resource owner password credentials (ROPC) grant (and the extension being the fact that you can specify a realm).

The at_hash does not apply neither to the original ROPC or extension grant so the behavior you’re describing is the expected one. Have in mind that the grant does not specify any response type parameter so what you’re sending is just ignored.

The library also allows to perform an authorization code grant through the authorize method, however, even for that grant the at_hash is technically optional so the client application could not enforce its presence (although if present the client application could use it to perform additional validation).

In conclusion, given that at_hash is required in implicit grant and some hybrid flows and that those flows are relevant to web application and not native applications you should not be requiring that claim to be present in your client application.

3

Is there a type of request that would be guaranteed to return the at_hash?

The server-side authentication method we’re using requires the at_hash to be present to compare against the access_token

4

Yes, like mentioned before when using the implicit grant that claim is required, however, that grant is only really suitable for web applications so to be honest the resolution should be to not require that claim when using a flow suitable to a native application.