I have a Web API that provides the user all the data that needs to be shown on my mobile application.
OWIN JWT Authentication is implemented and it's working properly. There's an endpoint /oauth2/token which provides the user a token and all the endpoints has [Authorize] attribute filter to validate it.
The token expiration is set to 5 minutes.
Login session is maintained through a separated SESSION-ID which is stored into the Keychain and also server-side to check the active session. Everytime a user login inside the application a new token is generated and the user can access API methods to get data.
The question
What if the user leave the application opened for more than 5 minutes (Token expiration time)? The token will not be available since it has expired, how can I refresh it? And when should I refresh it?
I read about refresh tokens but not sure how to handle them (Is thist the right choice?), since the [Authorize] attribute will just reject my call if the token has expired, without providing an expiration message, I can't understand when it is an expired token or an invalid one.
What if the user leave the application opened for more than 5 minutes
(Token expiration time)? The token will not be available since it has
expired, how can I refresh it?
If I understand right, you set The token expiration to 5 minutes, that means if the user leave the application opened for more than 5 minutes, the token is no longer valid. Actually the user has to relogin to get the new token.
So back to your question, at the moment the token is expired, my advice is you can present the loginPage and tell user that he has to login again to use the app.
I don't know if there is another way to get a new token, if there is one, use may not have to relogin,.
Also, I found a thread that may help: webapi-2-0-how-to-implement-refresh-jwt-token-when-access-token-expired
Related
I have an application to save Azure Active Directory users to SQL Server. For this I am using MSAL authentication to get the users.
But sometimes my access token will get expired and I will get 401 unauthorized error from Graph. So I need to add the logic of validating the expiry in my code itself. I searched a lot but couldn't find a good solution.
Could anybody help me how to achieve this?
The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average). I suggest you save the Refresh token instead and then obtain the access token any time you want to query the users resource.
The reason for that is that the Refresh tokens have a longer lifetime than access tokens. The default lifetime for the tokens is 90 days and they replace themselves with a fresh token upon every use. As such, whenever a refresh token is used to acquire a new access token, a new refresh token is also issued. The Microsoft identity platform doesn't revoke old refresh tokens when used to fetch new access tokens. Securely delete the old refresh token after acquiring a new one. Refresh tokens need to be stored safely like access tokens or application credentials.
More about Refresh token in Microsoft identity platform can be found here - https://learn.microsoft.com/en-us/azure/active-directory/develop/refresh-tokens
I am trying to build an API on ASP.NET Core 5. My authorization is implemented using JWT and refresh tokens.
As I understood, when the user registers, we provide him an access token (that expires in ~5 minutes, usually) and a refresh token (long-lasting one). We store refresh tokens in our database.
My struggle comes into play with login requests. In all of the tutorials we must decalre a method with the name like "GenerateAuthResultAsync()" that gets called on registration and on login and writes a refresh token object data to our DB. As a result, on login a new refresh token gets generated, as well as on registration. It is possible, that there would be 2 valid refresh tokens available for a single user. Is it normal?
I am making an API call that requires OAuth2. I initially make the call and authorize it with a login via the web. I'm then taking the supplied Refresh Token and using it to make subsequent calls in my application.
The issue is that in the subsequent calls the Refresh Token is used up and I get a new one. I save this new one in the database and then use that saved one on the next call. This works great for about xx number of calls and then for some reason the Refresh Token goes bad and I have to go and manually grab one through the web login again.
I have no way to tell, that I know of, when the token goes bad or why.
Is there a way to just send the login info or the OAuth2 info or something that'll get me a new valid Refresh Token without me having to "authorize" my own app?
The API that I am using is Constant Contact.
The OAuth standards are based on 2 forms of expiry:
ACCESS TOKENS
These are short lived API credentials and a common lifetime is 60 minutes. When they expire the API client receives an HTTP response with a 401 status code. The client can then try to silently renew the access token.
REFRESH TOKENS
These are long lived credentials that represent a user session, and a common lifetime is 8 or 12 hours. During this time the access token can be renewed silently. Eventually however, the refresh token itself expires and the silent renewal request results in an error with an invalid_grant error code.
USER RE-AUTHENTICATION
There are very good reasons for making users re-authenticate and I would avoid trying to bypass this. Tokens that last for a very long time are not recommended. Usability can be pretty good with only an occasional re-authenticate operation, along with features such as password autofill.
FURTHER DETAILS
See steps 26 and 29 of my Message Workflow
Code that handles 401 checks
Code that handles ErrorCodes.invalidGrant
I have implemented a JWT authentication and a policy-based authorization in ASP.NET Core. There is a certain user with admin privileges who can assign permissions to non-admin users. If the admin updates the permissions/claims of a non-admin user, is there a way to force expire the access token so that user carrying it will be forced to request a new access token with the newly updated permissions/claims? Right now, the only way to that is to wait for the token to expire but I want to force expire it immediately.
Authentication based on JWT tokens is stateless in serverside. So when a token is not expired it will work. There are some approaches to the problem:
Not including the roles and permissions in the token claims and getting these values from the database in each request.
Using refresh token mechanism and set a refreshing time to a few minutes and return a new token when refreshing time is expired. Therefore for the tokens with the expired refreshing time you know to get the new access permissions(not in each request). New permissions will set in few minutes but the authenticated user doesn't need to log in again.
Creating a set of black-list tokens and append the last issued token to that (not recommended).
I have a web API in C # (no core) to which I integrated JWT, so there is no problem, now, I would like to know how to revoke a JWT that currently exists, delete it before it expires.
That is, my JWT lasts a total of 20 minutes, but when I close the session, in my APPS I delete that JWT so that they can no longer use it, but in the API, that JWT remains active until it expires for time, how can I delete or expire that JWT in my API?
So basically you want to make inactive just one Jwt token issued by your Api while rest of them are still active. You can't do this straightaway.
Most feasible solution would be to,
Have a smaller lifespan for the Jwt tokens. Then you have to implement refresh token logic as well. If already in place you are good. Now if you want to inactive the token for specific user you can remove the refresh token from the back end. Then the next time user try to refresh, it fails. But still he can access the system until the issued Jwt expires. So make it's lifespan small such as 1 or 2 minutes so that the impact is low.
Cheers,