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
Related
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
I've spent a past couple weeks or so scouring through .Net Core docs and tutorials and now I'm building my first .Net Core web app. So the app basically consists of pulling data from an online API based on search parameters. Nothing spectacular. Now, my problem lies within OAuth2 the API uses to limit access to its data. It's my first time encountering OAuth2 and working with remote APIs in general, so as you might figure I've spent the last couple days going through OAuth documentation and learning about API consumption. The API I use to fetch data is Amadeus API and the duration of the access token I am granted is 30 minutes. So after banging my head for a couple days and trying to refresh my Access Token by all different kinds of means, I figured Amadeus doesn't even provide Refresh Token and I should basically use ClientId and ClientSecret to renew the access token when it expires or when it's close to expiring. My app doesn't have any user authentication and just serves to get data from the API.
So my questions are:
1) What is the best practice to renew Access Token if you are just granted ClientId and ClientSecret?
2) Is there a way to automate this process by using some in memory data and not relying on 401 response to check if my token has expired?
My guess was trying to use Outgoing request middleware to try and access request specific data or data stored in memory like, let's say, the time last Access token was generated and then deciding if I should renew it or not, before sending the request. My problem is I'm not very adept at this and I'm not sure if I can access my HttpClient instance inside this middleware and renew its token with HttpClient.SetBearerToken() method. I've tried using HttpContext as well but I'm not really sure how it works behind the scenes and Microsoft documentation that I've found for it is rather scarce. Thus another question would be:
3) Can I pass HttpContext to a custom middleware like in this case but use it to override a method like SendAsync() and then in conjunction with that, based on the intel I gather, use HttpClient.SetBearerToken() within that same middleware to update my transient HttpClient instance which is generated by HttpClientFactory?
Any help or advice is much appreciated !
1) What is the best practice to renew Access Token if you are just
granted ClientId and ClientSecret?
You cannot renew an Access Token without a Refresh Token. Your only option is to create a new Access Token which means going back thru the OAuth Authorization Flow.
2) Is there a way to automate this process by using some in memory
data and not relying on 401 response to check if my token has expired?
If you can hack the memory of a machine, maybe. However, using supported methods that will continue to work today and tomorrow, the answer is no.
3) Can I pass HttpContext to a custom middleware like in this case but
use it to override a method like SendAsync() and then in conjunction
with that, based on the intel I gather, use
HttpClient.SetBearerToken() within that same middleware to update my
transient HttpClient instance which is generated by HttpClientFactory?
I have no idea. Since the answer to #1 is no, you probably cannot. Note that setting a Bearer token does you no good if the token is expired. Tokens have a signature that you will not be able to defeat unless you have the Private Key or a million CPUs for a million years or a vulnerability/weakness is discovered.
I am using resource owner password flow and i got successfully access token and refresh token and i did not persist any token in database and everything works fine locally.
But when i deploy identity server in production refresh token is not working as expected.
i have set access token expired time 20 minutes and refresh token expiry time 7 days.
if i refresh access token within 20 minutes or before expiry of access token then refresh token refresh access token and work as expected but after expiry of access token refresh token does not refresh access token and throw invalid_grant error.
As i did not save refresh token in database and i searched on google but answers are confusion.
So can anyone tell me :
Do i need to store refresh token while it is working fine locally without storing ? if yes any implementation reference i am using mysql as database.
or something else i need to look.
Thank you.
Your response is valuable for me.
When running IdentityServer4 locally and "out of the box", things like refresh tokens aren't persisted and that's usually fine in the early stages of development.
When planning to deploy your Identity Provider to a server however, you'll need an operational store anyway (for storing grants, user consent, etc.).
This operational store can also store refresh tokens and reference tokens (read up on it in the IdentityServer4 docs).
Setting up token storage on the IdP is a good idea. Storing tokens opens the door to clean token revocation. A cleanly implemented sign-out in a client application would call the token revocation endpoint on your IdP. That's because when a user logs out, neither the access token nor the refresh token is needed any longer.
You can also revoke tokens from your end, making subsequent API calls fail for that access token and there are some compelling use cases for that as well.
Background:
I have a mobile application that stores a users asp.net identity token (encrypted) for the back-end web API.
I managed to find myself in a situation where my debugging database was completely corrupted, so I dropped and recreated it using Migrations.
As part of the Seed() method, the database gets populated with a single user, which has the same credentials as the last user, just a different ID and Security Stamp.
I've found that if I send any HTTP requests to the API using the token belonging to the now deleted user, without logging the new user in, the web API still grants me authentication.
Also, if I call any Identity functions on the current user, such as HttpContext.Current.User.Identity.GetUserId(); the old users information is returned.
Question:
So long as the token hasn't expired, will it always be valid? - Even if the user has been deleted / logged out?
(After some more digging about, I noticed that logging a user out, then sending a new request with the old token still works).
If this is by-design, how is this safe? (Is there anything I'm supposed to do as the developer to revoke tokens?)
Typically the token is only rejected if the validation interval has elapsed. At that time, it will check the token's security stamp and if it is still valid then it automatically refreshes the user's claims from the database, and if not will throw a not authenticated response.
If you want to propagate role changes immediately, then you need to change things up so it checks the database every time a request is made. See more on that here.
I am running a workflow service which automatically posts messages from some blogs on a facebook page. But now facebook deprecate the offline_access permission and I need to find a solution if my application does not run for example 60 days and the access token expired.
I need to find a way to get a new access token with given username and password without user intervention...
Maybe someone of you have a good idea
If your service make timed requests to the Facebook API, you won't need to worry about the token expiration. So, if you request some status or a specific FQL on a timed interval, your token will be extended and will let you post anytime you want.
This solution is a workaround. Even you try to do that, you won't cover all the scenarios. The better way is to mantain the user connected to your app, verifying some constant content day-by-day. With this behavior, you will have an access token for every entrance of the user.
Hope it works.