Implementing personal access token

[amit9]

In the absence of per user personal access token Personal Access Tokens or API Keys, was wondering how are auth0 customers implementing this feature? Are they managing the tokens inside their app?

[tyf]

Hey @amit9 - The only possible approach I’m aware of currently would be essentially using client credentials via an M2M app per user. Outside of that it’s not something that’s supported for the time being. I saw that you added to the feedback request, thanks for that!

[vlad.pesternikov]

Regarding M2M approach per user, is it possible to attach auth0 app metadata to access token? By attaching app metadata I mean attaching to token within rule not user metadata, but application metadata in case we request access token with client_id and client_secret.

[tyf]

Hey @vlad.pesternikov welcome to the community!

@vlad.pesternikov

By attaching app metadata I mean attaching to token within rule not user metadata, but application metadata in case we request access token with client_id and client_secret.

That should be possible, see:

Authenticate third-party apps

Hello @kvirk welcome to the community! While not “officially” supported (see this feedback request) - You’re on the right track in terms of what you can achieve with Auth0. I assume you mean the associated third party app in this case? If so, you might want to look into using an M2M flow action in order to add a custom claim. Taking advantage of app_metadata could work in this use case. Hope this helps!

[amit9]

Thanks @tyf for the prompt reply. I tried the following things and none of them seem to work:

• Rules - i had a rule which will add user metadata into the JWT token for the PKCE flow and it works fine, i just extended it to take care of M2M

function (user, context, callback) {
  const namespace = "https://unskript.io/"; // my_namespace is a placeholder...
  const user_metadata = user.app_metadata || {};
  if (user_metadata !== {}) {
    context.accessToken[namespace + "app_metadata"] = user_metadata;
  } else {
		context.accessToken[namespace + "app_metadata"] = context.clientMetadata;
  }
  return callback(null, user, context);
}

• Actions -

exports.onExecuteCredentialsExchange = async (event, api) => {
  api.accessToken.setCustomClaim("https://foo.bar", event.client.metadata)
};

When i do the curl POST to get the access token

POST https://<YOUR_AUTH0_DOMAIN>/oauth/token
Content-Type: application/json
{
  "audience": "<API_IDENTIFIER>",
  "grant_type": "client_credentials",
  "client_id": "<YOUR_CLIENT_ID>",
  "client_secret": "<YOUR_CLIENT_SECRET>"
}

and i parse the JWT token, i dont see the custom claim or app_metadata. What am i doing wrong here?

[tyf]

No problem, happy to help!

@amit9

and i parse the JWT token, i dont see the custom claim or app_metadata. What am i doing wrong here?

Your action looks good - Are you positive you have it set on the Machine to Machine flow (Actions → Flows → Machine to Machine). I just tested with the same action and it’s pulling the claim and app_metadata through to the token.

[amit9]

Oh you know what i just created an action and didnt put it in the flow. Its working fine, however the rules way didnt work, any idea why?

[tyf]

Great! Good to know the action is working as expected You’d need to use a hook instead as rules won’t apply to an M2M flow.

Getting client metadata in non-interactive clients access tokens

You should be able to accomplish your requirements by implementing a client credentials hook that will let you add additional custom claims into the issued access tokens. The hook logic would have access to the client metadata data and as such you could add the claims you are interested to received in the API. Have in mind that custom claims added need to use a namespace so there’s no risk that they clash with standard ones. A sample implementation for the hook could be the following: module.e…

[amit9]

Oh good to know. One last question @tyf , M2M access tokens derive the expiration time from the API attached to it and AFAIK, API cant have indefinite expiration. Any way, we can achieve indefinite expiration for such tokens?

[tyf]

Hey there @amit9 just following up on this - While there is no way to mint access tokens that don’t expire, in an M2M flow you should just be able to request a new token when needed. The following posts outline this:

Request new M2M token after expiry date

Hello, @katab, Before moving on, it’s good to understand the concept of a Machine to Machine Authentication. This grant is intended for non-interactive clients, where a machine is requesting a token to be used on behalf of itself (never on behalf of a user). If you are using this token on behalf of a user, you have chosen the incorrect grant. As such, the machine should be able to understand when the token has expired, and just request another one, as the machine itself, considering it’s a sec…

Correct way to handle M2M token renewal?

This looks pretty standard. A refresh token and a client secret are very similar when we boil them down in a client credentials grant. This is a secure server, correct? If an attacker has access to your server you probably have a bigger problem than just the tokens, your client secret is more powerful.