Hi all,
Imagine a product that gives users access to its API through tokens, like GitHub. I’d like to know if it’s possible to implement such a functionality using Auth0. The token should be unique for each user and they should never expire unless users regenerate/remove them. I’d appreciate your thoughts on this.
Thanks.
3 Likes
Perhaps you are looking for a functionality to protect your API via token based authentication.
Well, the answer is Yes Auth0 can be used to meet your requirements.
Please refer this doc to get a better understanding, and revert back in case of any queries.
Hope this helps!
Hi @priya.sharma.9362
Thanks for the info but I could not find what I was looking for. Imagine I have developed an API that translates text from english to spanish and I want give other developers access to use that API - however the developers need to sign up to abel to do this. Once registered, developers need to put some sort of API key or access token in the request like below:
https://example.com/api/text=hello& api_key=xxxxxxxxxxxxxx
The system should be able to generate many API keys depending on the number of registered users. Now is that something that I can achieve using auth0?
Thanks
You can use Auth0 to sign up your develpoers either by username-password based authentication, or social entity provider based login , and on successful login they will receive an access_token generated by Auth0,
You can configure your server to accept and validate those tokens based on the unique identifier you embed in the token i-e. audience claim, explained here.
If the token is valid, grant access to the developer to the API else deny request.
For the type of token you are looking for, you could use the concept of refresh tokens here
Here is the complete explanation doc
@priya.sharma.9362 the problem with access_token is that it’s got an expiry and it isn’t checked against blacklistings. Would you say that using a refresh_token, in this case, is the appropriate approach?
That means the server would receive a refresh_token (that was generated for the client and sent to them to be used in every API call), validate it upon receipt and generate an access_token for each of these API calls internally to be used for authorizing the request.
Or is there a better approach for a token that is sent via the API, never expires, and can be blacklisted?
(BTW, the closest flow in the documentation is Resource Owner Password Flow , but it still shows the access_token being used and not the refresh token)
Hi @ruby
Looking at the docs I can infer that the refresh_token and access_token both will be stored on the client side, the client would request a new access_token if it is expired, using the refresh token.
Each user would receive a pair of access_token and a refresh token. The server would not receive the refresh token, client
would request Auth0 for access_token using the refresh_token, and send the access_token in order to access the API.
Here s a useful link
This process is good for sophisticated clients. But, as @ebrahim.poorazizi mentioned above, the intention is to expose an API that receives a single token. Without refreshing it first or getting some other token, checking expiry time, etc.
We’ve implemented something similar to what I described above, which uses the refresh token. That allows using a single token that never expires, and still be able to invalidate it.
Is that approach wrong? Is there an alternative that you can think of that provides such a simple auth technique for a 3rd party system?
1 Like
Let me clear, I am no expert 
But please understand refreshing of the token will be done at the side which is requesting access to the API and not at the API end.
Thus the API end will only be expecting an access_token and validating it to grant access.
Though this is the recommended approach, and also A Refresh Token is a special kind of token that contains the information required to obtain a new Access Token or ID Token.
So how will you make sure that this is the token you were expecting, thus I am sure this is a good idea to use refresh token directly.
Thanks @ruby for clearing this up. It makes sense to use refresh tokens to grant access to an API in a client application like an SPA, but IMHO it doesn’t when trying to do API calls using api keys / tokens. That’s because using a refresh token the client should do a 2-step process: (1) getting a new access token using the refresh token, and (2) using the new access token to invoke the API. In the use case I described, there should be only one access token that never expires, but could be revoked, and that token should be sent to the API server in every request.
As per the concept of refresh_token, it saves you from re-authenticating you user once the access_token is expired. The user will never know that the access token has been expired.
Thus it provides you a streamline flow while accessing the API. You can also revoke a refresh_token , see here
Further, my concern is that a refresh token is an opaque string, how can we make sure that it is a valid token and authorized to grant access?
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
Hey there!
Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.
Wanted to reach out to know if you still require further assistance?
1 Like