How to get access token with HMAC algorithm?

Help
1

Hi,
I am able to use RSA and able to get access token from /oauth/token. I have changed the signing algorithm to HMAC in the registered client application.But I am unable to get HMAC “client_secret signed” access token to access the API where i pass the token. If i use the client_secret to create the token manually from jwt.io then the created token can be used to access API. Can u tell me how to get the access token from the token endpoint when algorithm is HMAC without using any library.
Regards
Rimpy

3

Hi @rimpy,

I am looking into this! Just to make sure I understand, you have configured your application to use the HMAC signing algorithm, but when you sign in to the application, the token you receive from /oauth/token is still using RSA. Is that correct?

Also, in your application’s advanced settings under OAuth, is the OIDC Conformant checked? This would prevent the use of HMAC.

You may also want to look into why RSA tokens are recommended:

https://auth0.com/docs/tokens/signing-algorithms#our-recommendation

4

Hi @Stephanie,
Thank you for your reply. I am trainer and i have to demonstrate both RSA and HMAC so i need to know both.
I am listing out the steps that i have taken -

  1. registered a machine to machine application with auth0, changed the JsonWebToken Signature Algorithm to HS256.
  2. As an answer to your question, i unchecked the OIDC Conformant as suggested by you but it still didnt work but could u please guide me why it need to be switched off?
  3. used client credentials grant type and /oauth/token to get the access token
  4. passed this jwt access to token to an application which is not part of Auth0
  5. The expectation is that another application can use client_secret to decrypt the jwt token but i have received invalid token
  6. To check if it is another application’s error or auth0 error, i created a jwt token from jwt.io using the client_secret of auth0 and passed it to another application and another application could verify it without any problem using the client_secret.
    Another application in this case is - MuleSoft Policy in API Manager for which i have not written any custom code, it is already written by MuleSoft.
    Thank you!!
5

Thanks for the details @rimpy! I did not catch that this is for a machine to machine application before.

The “JsonWebToken Signature Algorithm” setting is not relevant for machine-to-machine applications. This setting refers to the ID Token which isn’t issued during client credentials flow.

Likewise, the OIDC Conformant is not relevant for machine-to-machine applications either (only SPAs/Web apps).

In order to change the signing algorithm of the Access Token, you’ll need to register a new API that has the HMAC algorithm.

6

Hi @stephanie.chamblee
Thanks for pointing this out. I will use Authorization code grant.
I have two questions here -

  1. It seems to me that i need to first register my API in this case - both for RSA and HMAC?
  2. If I use Authorization code grant , what is the validation endpoint url for my access token. The Id token is in jwt format and access token is not in jwt format. For Id token, i can use the endpoint referring to jwks but i dont know which endpoint to use for access token validation.
    Thank you!!
7

You’re very welcome!

You can only register an API in Auth0 with one algorithm. In order for your API to support both, you’d probably need to register two APIs in Auth0 and set up your API to use two sets of credentials when initiating whichever Auth0 SDK you are using.

If your application is an API with no user interface, then Machine to Machine client credentials flow is the way to go. You’d only want to use Authorization Code flow if a user logs into your application. Here is a guide on how to choose which OAuth 2.0 flow to use: Which OAuth 2.0 Flow Should I Use?

If your application is not just an API, but instead has a user interface where end-users must log in, then you’ll need to provide an audience (API identifier) when you initiate the Auth0 SDK. Auth0 will provide an opaque Access Token by default if no audience is specified. If an audience is provided, then it will return a JWT for the Access Token.

Here is an FAQ on opaque versus JWT Access Tokens: Why is my access token not a JWT? (Opaque Token)

Let me know if you have more questions! If you do, could you tell me a bit more about your application (what Auth0 SDK you are using, what kind of OAuth 2 application is it)

Thanks!

8

Hi Stephanie,

Let me explain my scenario -

  1. A client application - webapp is created/registered in Auth0
  2. Using Auth code grant type, it gets logged in
    https://dev-abc123.us.auth0.com/authorize?client_id=&scope=openid &redirect_uri=http://localhost:8081/adminapp/callback&response_type=code
  3. Gets IDToken and Access Token
  4. uses the access token to connect to an api which is outside auth0 - mule api which has a way to authenticate an access token if it is jwt token and jwks link is given

I was able to use client credentials , get the access token and could use it again mule api but now two cases are pending

  1. first client app,get the jwt access token in case of auth code and use it to access the api
  2. second application, get the hmac token and use it to access another mule api with whom client secret is shared.
    Hope this clarifies my scenario
    Thank you!!
9

Thanks for clarifying!

To get a JWT Access Token instead of an opaque Access Token, you would supply the identifier of the external API that you’ve registered with Auth0. This would be the audience that you send in the /authorize call. for example: https://dev-abc123.us.auth0.com/authorize?client_id=&scope=openid &redirect_uri=http://localhost:8081/adminapp/callback&response_type=code&audience=API_IDENTIFIER

To accomplish this you would need to send a different API_IDENTIFIER in the /authorize request. This API identifier would have to refer to an API that is registered to issue an HMAC Access Token.

1 Like
10

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.