I built an express REST API and now wanted to integrate Auth0 the problem is that after reading countless articles and tutorials in the docs I couldn’t find an answer for my use case.
My thinking process goes as follows:
Have an API
Have a front end for users to register and where I after they pay generate them an API key or access token that is public and restricted to only reading from a certain domain (theirs) and that’s pretty much it
I’ve looked into M2M and SPA - API that are the most akin to my use case but I need to generate public tokens with certain restrictions
I think we need some clarification on this one. Do you mean your users are developers who are going to use your API? Or are you talking about how to secure some endpoints when a certain paying user is using your application?
Yes, my users are developers who are going to use the API and since this is a must they’ll be doing cross-site requests. I’m looking a way to generate them an api key that’s is public so they can make authenticated requests against the API and I can monitor their quota limits, requests and so on.
I initially though on using SPA - API but that infers that the only one using the api are the users using my SPA and that’s not the case.
My thought was using the login widget, write a rule to given them read:fares permission and use the access token for calling the API but this access token is not public.
We don’t have a buit-in method for creating API keys so that a third party (like a customer/user of yours) can consume your custom API. There has been discussion on it in the forum, but it isn’t something I have seen implemented, or at least not a process that is well documented here or in our documentation.
The way I have seen this use case covered is by creating an application for each user and making the client id and client secret available, which would let them request an access token for their app via the client credentials grant. This takes the ‘user’ out of it and is more of the OAuth way of doing things. You can create and delete applications (client id/secrets) programmatically using the Management API. Beware of the entity limits for each subscription type.
One of the issues with handing out access tokens is this: they are not long-lived. Particularly tokens destined for SPAs. Usually, they expire after ~24hrs. They are meant to be refreshed on a regular basis, keeping the info in them up to date and making them less useful to an attacker who gets ahold of one, due to their short-lived nature.