How do I enable programmatic access for refresh tokens for API authorization (cf. https://learn.microsoft.com/en-us/linkedin/shared/authentication/programmatic-refresh-tokens?context=linkedin%2Fcontext )?
Related
I have built one authentication using access token, refresh token and refresh token rotation. When a user login, the system generates one JWT token and one UUID hashed refresh token and its refresh token id then return back to user.
The init refresh token is a UUID token and it uses bcrypt to hash the uuid token then saving on the database. On the database, apart from saving the refresh token id and the hashed token, I also saved its expired date, its userId, active status and revoked ip.
The access token is passed inside Authentication header as a Bearer token for JWT verify. When one access token is expired, it calls /refresh-token with the old refresh token value and its id to get a new access token and refresh token pair. If the refresh token is expired, I will ask the user to login again.
I also have a refresh token rotation method to avoid refresh token reusing. When a refresh token reused, I will revoke and disable all the refresh tokens belonging to that userId family. So the user should login again to get the new access token and refresh token pair.
I know OAuth2 is a good protocol to implement access token and refresh token authentication. With my authentication design, how to improve it to make it with OAuth2?
Well it sounds like your UUID has all the powers of a refresh token to a client. And if the client is a browser it should never receive a refresh token - a secure cookie is considered better.
The main things I would recommend are the use an Authorization Server and to follow standard guidance around APIs, web and mobile apps.
OAuth provides a number of security design patterns. It is worth understanding the specifics of web and mobile clients. Also think about security related features such as auditing of tokens issued.
Here are some resources from Curity, where I work. The concepts here apply to any provider - it is the principles that matter:
IAM Primer
Free Authorization Server
Guides
How to implement the refresh token flow in Loopback 3.x ?
Some have recommended to refresh the 'created' columns of access token table, so the access token does not expire. But this results in a 'long-lived' access token. This is a security flaw.
I have used jwt token securing angular application and in the backend, we have used asp.net core API. After login successfully we have saved the token in local storage in web browser memory and we log out from the application simply remove the token from browser memory.
We can stop the user to access the application through the application but if some have the token he can access the endpoint using postman and other api test tool. How can we overcome this problem.Is there any way to remove the token or expire the token manually.
Revoke the jwt token is not easy , there is no standard way to revoke access tokens unless the Authorization Server implements custom logic which forces you to store generated access token in database and do database checks with each request.
A simply way is using short lived access tokens and refresh token , use refresh token to renew the access token , if you want to revoke the user , revoke the refresh token on server side , clear refresh token and access token on client side .
Another way is reference tokens. The basic idea is Authorization Server will store the contents of the token in a data store and will only issue a unique identifier for this token back to the client. The API receiving this reference must then open a back-channel communication to Authorization Server to validate the token , so that the server side could control whether reference token(unique identifier) is still available . Identity server 4 also provides the reference token feature :
http://docs.identityserver.io/en/latest/topics/reference_tokens.html
I am currently working on an API with django rest framework, and I have a question about token (JWT or OAuth2) authentication.
Actually I have a doubt about the utility of a long-lived refresh token when the authentication server and the resource server are the same.
What I understand about refresh token is that when a user authenticate, the authentication server send in return a short-lived access token and a long-lived refresh token that we store.
When the user interact with the resource server we send the access token in the request and never the refresh token. And if the access token has expired, we ask for a new access token sending the refresh token to the authentication server.
By this way if the attacker get the access token, he will have a short window to use it because it is short lived.
But in the case of authentication server = resource server, if the attacker can compromise the access token, he can compromise the refresh token too. And he can get new access token easily, am I right ?
So what is the purpose of using a refresh token system in this case (authentication server = resource server) ? In my opinion this is the same as set a long-lived access token, but I'm not sure...
Thank you
I'm using the Google OAuth2 Javascript library to request an access token from users. I want to store the token in a database on the server.
To be able to access that user's data after the token expiration, I also need to store the refresh token. I know how to do that when using a server-side Google OAuth2 library (specify access_type=offline), but I need to be able to do it with the client-side Javascript library and it doesn't work.
You do not want to store the refresh token in the client! That would be akin to storing his username and password.
The Javascript client does not support type=offline, since that would expose the refresh token.
Your choices are :-
Generate and store the refresh token on the server
Have your client simply keep requesting access tokens as it needs them. Set immediate=true so there is no visible interaction with the user