In our application, we periodically encounter a scenario where the user requests a new token at the same time when we're automatically refreshing the token in the background (via JS.)
Both requests are using the refresh token & hitting the token endpoint.
If the automatic request finishes first, the user-initiated request results in an error. This is because both requests are trying to use the same refresh token but since it can only be used once, it's consumed by the first request and the second request gets 400 Bad Request.
My question is: What's the best way to handle the 400 response for the second request? Ideally, I want to silently retry the request and the user should be none-the-wiser.
If this occurs, the ultimate fall-back has to be reauthenticating - IdentityServer is doing nothing wrong, the ball is in your court.
But - you should be able to make this situation impossible by synchronising the automatic token refresh and the user-driven token request. If the refresh token lives in your application in one place, then you can regulate access to it via some kind of lock/release mechanism.
This npm package looks like it'd do it: https://www.npmjs.com/package/lock
Alternatively you could synchronise calls on the server by subclassing the relevant IdentityServer component, and using a per-client lock there - but IdentityServer is already complicated, it would require many locks in one place, and it wouldn't be easily scalable to multiple server instances.
Related
I am currently working on the logic of custom token validation. I need to deactivate the token when the user's password is changed (change-password endpoint is public).
I have implemented the ICustomTokenRequestValidator interface and resolved my class via DI
.AddCustomTokenRequestValidator<TokenHashValidatorService>();
However, I can see the following problem, my implementation of ICustomTokenRequestValidator only works when I generate a token and during only the first request to my API.
In logs I see the following information:
JWKS request from log
During first request to API request to /.well-known/openid-configuration and /.well-known/openid-configuration/jwks is sent. But when I send a second, third, etc. requests my breakpoint in TokenHashValidatorService is skipped.
Is there any way I can forcefully initiate second /.well-known/openid-configuration and /.well-known/openid-configuration/jwks requests?
Or maybe I can somehow mark that "token validation needed" during the change-password flow?
I'm really stuck and out of options, I've read all the articles out there, any ideas?
I have Web API.
Authorization is made via token from 3rd party API.
If request comes i check is token set -> if not, get it, set and use.
If response is 401 i need to try refresh token and then call API.
How to make it thread safe way and make other requests wait until failed one retries?
Request -> if token set -> use token, make request -> if response 401 -> try refresh token, make request one more time -> if failed, die.
All threads should use same token and not try to refresh it when some other thread already tries to do it.
I’m writing a web api that will be called from a background service to fetch some data. After some research I decided to use a Json web token to achieve that but I’m still a bit confused regarding when a new token should be requested.
Let’s say I start up my service, I request a token, the token expires after 15 minutes, then after 20 minutes I make an api call with the expired token. I will get an unauthorized error or something.
My question is: How will the client know when to request a new token? Should it request a new one before every api call? Seems like I’m missing something. Maybe I should make the token permanent and store it in the database?
Thanks
The answer to this is slightly application specific, but the OAuth specification has a mechanism for "refresh tokens", which can be used to grant new "access tokens" (the token typically included on each API request), without having to send the user to the UI authentication process to have them re-authenticate. So, once you request an access token, you will receive a refresh token and an access token. This methodology allows access tokens to be used for much shorter time frames.
This can also be done without refresh tokens, but in those cases the access token timeout would likely be longer, and then you would request that the user re-authenticate through the usual OAuth UI process. Note that even when you do have refresh tokens, the refresh token can also be set to expire, in which would then require a user re-authentication through UI again.
In some API's you just make the API request as usual, and if you get a response that is defined by the API to be one that indicates the access token has expired, you can then issue an API call to refresh the token (or fully request a new one if that is expired, or you the API doesn't have refresh tokens), and then make the original API call again with the new access token.
The API can also have a response that includes the timeout or expiration date/time of the access token as well. Then, the client can avoid sending the initial API call first, and simply send the refresh token call first.
In implementing your API, you could likely use any of these methodologies.
Here's some general discussion on the OAuth spec website, to provide more depth:
https://www.oauth.com/oauth2-servers/making-authenticated-requests/
https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
https://www.oauth.com/oauth2-servers/access-tokens/refreshing-access-tokens/
And also, here's an example from the Twitter API regarding response codes showing one of the access token expiration techniques (see the "Error Codes" section, under error code 89, which implies the token has expired and you need to get a new one):
https://developer.twitter.com/en/docs/basics/response-codes
Since your client is background service , you can use the Oauth2 Client Credential Flow . Your background service can request an access token using only its client credentials when the client is requesting access to the protected resources under its control.
With this flow , you does't need to care much about the token expires , if client sends an expired token to web api , web api validate the token and create token expires response to your service , your service check the status code/response , directly send a new token request to web api to get new access token , there is no need to use refresh token which uses in other flows .
The fact is that your harness should be prepared to request any token when getting an Unauthorized status code. What I do in test is to check the expiration datetime, if close enough I refresh or get a new token whatever applies to your Auth. Also when getting an unauthorized status code my code does a refresh once and keep a count. If I get another unauthorized code then I return a false or throw an exception after I log the error on the second try. This works fine for me.
I need help to obtain an authorize code, is there any way to get one without accepting anything or any window that pops up. I need this for my service as an automated process.
I tried like a thousand ways but nothing works.
Please does anyone know a solution?
As per the docs (http://msdn.microsoft.com/en-us/library/dn659750.aspx), you can use a refresh token if your app has offline access in its scope.
If offline access is set, when you retrieve your authentication token normally, you'll also get a refresh token. When the normal token expires, you can request a new one similarly to the first token, replacing the code query parameter with the refresh_token parameter.
To be clear, the process looks like this as per the docs:
Send your user to your web service
Direct them to the OneDrive authorise page with the correct parameters (make sure offline access is in the scope)
Wait for them to be redirected back to your app with the authorisation code
Exchange the authorisation code with OneDrive (using the oauth20_token.srf endpoint) to receive a set of tokens (one of these will be refresh)
Wait for the access_token you received to expire
Exchange the refresh_token you received for a new access token as per the "Getting a new access token or refresh token" section of the docs
We have some web services with OAuth on them.
I am required to run some tests against them, preferably in an automated environment without using a browser.
The problem is logging in.
Without using a browser, and with using DotNetOpenAuth and setting the HttpContext.Current manually, I seem able to do everything and get a request token and a verifier (I use a test username and password).
I believe the next stage is to get an authorising token. Unfortunatly, no matter how I construct the request, I cannot get it to work.
At the moment, using a WebConsumer (DotNetOpenAuth library) and calling consumer.ProcessUserAuthorization() results in an error:
DotNetOpenAuth.OAuth.Messages.AuthorizedTokenRequest message: oauth_verifier
Probably the whole approach is wrong, so any help/advice would be useful.
Thanks.
I would recommend you skip the entire OAuth handshake and authorization step by having a test access token and access token secret that your web service's token manager always includes. Then wiring your test to also have that token pair included in its token manager, and always using that access token when authorizing your outbound calls.
In the end, it was a problem with cookies not being stored properly.
I was losing cookies between the login page (where the user types their username and password), and the authorise page (where the user says it is okay to share details with the third party). The second page was doing an extra check to see if the user was who they say they were (reading a cookie value that the login page was meant to have written).
It was not really an OAuth issue, just something I did not understand in the Authorising page (which has since been removed anyway - c'est la vie).
I then had issues with the domains of the cookies (when the domain starts with a ‘.’). This post helped me:
CookieContainer bug?
I ended up copying cookies from one domain to another.