I thought that a workaround could be to sign the tokens manually in the server but it seems APIs access tokens must be signed with RSA and Auth0 does not provide the private key.
Note: my API is a Hasura endpoint and it handles authorization and roles through custom claims on the JWT, which is the reason I need to have JWT with custom claims per user.
Any other ideas into being able to provide API keys to my users?
We have a webapp that authenticates and afterwards users can get an access token to the API (on the webapp) with custom claims.
Additionally, since we are developing a SDK, we want to give users access to the API by the user having a key (or similar) that they would exchange for an Access Token in our backend. Ie if user holds valid key, backend signs and returns the access token. That was my intention but it seems this is not going to be possible, so I wonder if there is any other options for our case of user API keys to develop a SDK?
I don’t understand your use case, sorry. You can certainly do what you need here though:
Your backend generates access tokens and signs them.
You configure your API to accept access tokens signed by either your Auth0 tenant or the backend.
This is a pretty standard approach - to configure the middleware to accept multiple signers for access tokens.
But I don’t understand the use case here - it is still not clear to me why the user cannot just authenticate and get an access token. Why do they have to have a key?
Some thoughts: you might check out 3rd party apps:
Sorry, perhaps my writing is not very clear. I hope you bare with me one more time:
For M2M applications, we need to know which organization is the one accessing via the JWT with a custom claim. Is there a way to do this? (Example to have an extra field when requesting the access token that gets passed as a custom claim could be an idea).
As an example, Hubspot gives an API key to the organization, see Access your HubSpot API key.
I thought we could do smth similar where we exchange the key for an access token in the backend. The access token would have the organization identifier as custom claim.
I think what you need is client credentials (I linked to it above).
Each organization gets their own client credentials application in Auth0, which has a client ID and a client secret.
The organization then uses the client credentials flow to exchange their client ID and secret for a M2M access token. (The client ID and secret really are your “API key”).
The resulting access token has the organizations Client ID as the subject field.
When you say each organization gets their own client credentials application, you mean that we have to manually create a client-credentials application for them correct? So we are going to have as many client-credentials applications as we have organizations?
How do we link the Client id to the org id?
Another question, is it possible to customize claims in the Client Credentials tokens?
I would not say “manually”, I would say as part of your new organization onboarding app, it calls the management API and creates the client credentials application.
You can customize claims in the M2M token: you need to use an action or the client credentials hook (not a rule).
I am not sure about linking the client ID to the org ID. Your DB for the organization should include the client ID. (Note I am assuming “organization” does NOT mean Auth0’s “Organazation” feature - that is very different).
Ok to everything except the last part. I was referring to organization as in Auth0’s Organization feature (https://auth0.com/docs/organizations) , that gives an org_id in the JWT for the Authorization flow. In the end, what we need is to identify users/organizations in the Authorization flow or organizations in the Client Credentials Flow (for both cases in the JWTs), and ideally linking the org_id we get from the mentioned feature.
Ah, I was worried I had misunderstood about organizations.
Off the top of my head: I think you will need to set the client.metadata for the client credentials app to include an org_id when you create the app. Then you can reference this metadata in the hook or action to put the claim in the access token.
I actually am wanting to do the same operation as the OP is wanting to do. Basically, I am writing a B2B API that will integrate our back-end system with multiple third party vendors. However, these vendors may be deploying this application in a variety of scenarios, including onto desktop and mobile devices, yet will still need to send credentials to perform operations on our API. We do not want the end-user to have to perform any additional authentication to our API, as that should be handled by the vendors integrating with our system.
Basically, the vendor, will either contain the API keys on their back-end server or distribute the credentials to their clients that will be authenticated against our API through their client software.
It appears maybe there is some kind of workaround to allow this to happen, but it seems a little complex. I am wondering if I will be forced to maintain my own user database on our server, which was something I was hoping to avoid by using AUth0. Requiring MFA is just not feasible for this type of application.
I am basically trying to implement a security setup like Twilio, which allows you to have multiple levels of API keys, one set for administrators and then to create multiple sub-levels of api keys that can be accessed only by specific users.
Hey everyone, I also think this would be a really useful feature. I’m interested in building this as a marketplace integration with Auth0. Would you mind dropping your email at my landing page if you’re interested? Currently gathering validation of my own, I’d love to build this for the ecosystem! https://www.keysync.io
