Enabling silent refresh using angular-oauth2-oidc results in triggering of a series of calls to fetch the token after ten minutes. It is observed that more than 100 calls are triggered to fetch the new token. I have not set any timeout Factor value, all the settings are by default. I have used this.oauthService.setupAutomaticSilentRefresh() in my code to enable the silent refresh. Please help me how can we stop so many calls. Ideally, I think there has to be only one call fetch the refresh token based on the time out factor value or once the token expires.
Related
I am using the Gmail api to send e-mails from my Oracle database.
After a while, the Oauth2 token expires and the token needs to be refreshed with, using the refresh token.
All of this works fine (in both Postman and Oracle).
When the mail has not been used for a while ( a few weeks) the refresh token doesn't work anymore.
Then I need to get a new authorization code etc. It seems as if the gmail-api revokes its grant after a certain time.
Is there a way to work around this ?
thanks in advance.
Servé
There are a number of things which can cause a refresh token to expire here are my top three.
Applications that are still in testing, and have not bee though the google verification process will have their refresh tokens expired within in two weeks.
If the user changes their password this will also cause a refresh token to expire when using the gmail scopes.
If you authorize the app, then authorize it again you get two refresh tokens both will work, you can have up to fifty outstanding refresh tokens once you have hit that number the first one will be expired, as you can maximum have fifty outstanding refresh tokens.
Have a look at the possible refresh token expiration reasons here: https://developers.google.com/identity/protocols/oauth2#expiration
AD-FS define refresh token life time to be equal to SSO lifetime. What would be the new refresh token life time, if we replace the refresh token with the newly acquired refresh token which we get in access token call.
For eg : If my ssolifetime is 720 mins(8 hrs) and after 6 hrs i make a call to get new access token which will also return a new refresh token. What would be the ssolifetime for this new refresh token. Is it 2 hrs(as 6 hrs is already elapsed) or it works in sliding manner and new life time for this newly acquired refresh token would be another 8 hrs starting from 6th hr.
If I understand correctly, in ADFS, if you are an unregistered device, and you don't use Keep me signed in option when signing in, then the Refresh token is = to the sso, which by default is 8 hours.
the way I understand it is you do NOT get a new refresh token in this scenario. so if you renew your token before the 8 refresh token expires, I would think your access token is good for another 8 hours, but your refresh token is no good anymore, so next time you try to get a new token it will fail.
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-settings#enable-psso-for-office-365-users-to-access-sharepoint-online
there's also Persistent SSO, for authenticated devices, and keep me signed in for unauthenticated devices, they all behave differently. but there is no indication that a unauthenticated device without "keepmesignedin" would ever get a new refresh token in adfs.
Session SSO cookies are written for the authenticated user which eliminates further prompts when the user switches applications during a particular session. However, if a particular session ends, the user will be prompted for their credentials again.
With KMSI disabled, the default single sign-on period is 8 hours. This
can be configured using the property SsoLifetime. The property is
measured in minutes, so its default value is 480.
I hope this helps a bit.
Hi I'm developing a React app that communicates with an Express API. I'm trying to implement JWT authentication but I don't know what should happen when the jwt expires. It not seems very user friendly if the user is logged out when the token expires.
Should I use refresh tokens? As it says in the node-jsonwebtoken package documentation (jsonwebtoken). This may not be the best approach.
Should I create a new jwt in every request to the server? If the user reads an article for a long time without doing any request, he is going to be logged out.
Maybe I'm wrong and the best practice is using a big expiration time and let the user be logged out. If this is the case what would be a reasonable time?
Thanks!
A pattern commonly used along with refresh tokens is to follow a workflow along the lines of:
Some API call / resource returns with a 401, alerting that the token has expired, this sometimes is accompanied by a reason, e.g. Expired token, invalid token
Create a reference to the API call that failed, to retry later
Attempt to refresh the token with the refresh_token
If the refresh works, go ahead and perform the queued API call again
If the refresh fails, the user will need to log in again
You can also use the above approach to queue multiple failed requests, in the event that multiple calls fails whilst a refresh is taking place.
Coupled with a decent expiry time, which really depends on your application, this has proven to be a robust solution in the past for me.
An alternative approach would be to implement a 'heartbeat' API call that updates the user's token periodically whilst they are on the site, however this may come with side effects that may not be desired.
I am currently working on a web application that uses a JWT for authentication on all REST calls. The problem we are having is when a customer is performing an action needing a REST call and the JWT is expired, for whatever reason. At that point it kicks back a 401 response, as it should.
The functionality I am looking for is some way to intercept the 401 error, refresh the JWT, and retry the request without sending errors to the user.
The application runs on AngularJS and uses Restangular to handle all of the rest calls. So far I have been looking closely at the setErrorInterceptor as outlined here and at the Restangular documentation. Using a version of that posted code, I could successfully resend the request and in the .then() portion I had a successful response. However, it seems from the documentation that this method can only return false or true, so I couldn't get at it.
At the moment we have a timer that basically compares the jwt expiration time to the current system time and refreshes the jwt when there are 60 seconds left before expiration. This caused issues when the user's system clock was off compared to the server clock, resulting in a token not being refreshed because the application thought there was more time.
A solution to that specifically would be something like getting the system time, comparing to server time and creating an offset variable, but that doesn't cover all the bases for things that could go wrong. On another topic, checking the JWT before every request is not feasible.
Is there a way within Restangular's interceptors to accomplish the error interception and resending? If not, are there ways outside of it?
I'm using JWT for authentication in my Angular.js application, with Express.js on the server side.
Basically, when user logs in, a new token is created (using https://github.com/auth0/node-jsonwebtoken) and send back to the client. If token is valid also on the client side (angular.js part, using https://github.com/auth0/angular-jwt), a new user is created and the token gets stored in a cookie.
So, each request to certain path on the server is protected by a token validation. However, my token has an expiration time. Now let's say for the sake of argument that expiration time is 30 seconds; user can actively use my application for 30 seconds and after that, he gets logged out. That's not exactly user friendly.
So what I did was that with each request to the server, I create a NEW token and send it back in the head of response. When I receive the response in my Angular.js client-side, I read the token and overwrite the token in the cookie. That way, as long as client is active (or rather, makes requests to the server side), the token gets refreshed.
Now I'd like to know the following:
Is such an approach correct? The downside is, that token gets created at each request and send back in each head of response. Cookies get overwritten quite often (performance issues?)
What would be the correct approach?
Is it OK that the token expires if there are no requests to the server? Client might still be using the application, however, if he's only writing on client side something (or reading), the token does not get refreshed.
Thanks for your time and responses!
Yes, that is a valid approach. It is the same approach many take,
including the popular Angular module ng-token-auth. You might
consider saving the tokens to local storage, with a fall back to
cookie storage if the browser doesn't support it (see
http://caniuse.com/#feat=namevalue-storage for coverage).
I would do what you describe.
One solution is to use $interval to basically ping the API. All you need to do is send in a token a get a new one back (i.e., in headers like you are now). Keep track of how many "pings" you've sent. You can reset the number of "pings" upon certain actions like on ui-router's $stateChangeSuccess (i.e., navigating to a new view) or anything you like, including submitting a form or other non-ping requests. When the number of "pings" reaches your threshold, warn the user that their session is expiring, and after a delay, erase the stored token and log them out. Check your ping responses for authentication errors from the API, indicating that the user might need to be logged out and/or redirected.
Perhaps you just gave 30 seconds as an example token lifespan. I would recommend getting closer to the browsing session timeout that you want. As points of reference, consider that the Ruby gem devise_token_auth defaults to 2 weeks and that .NET defaults to 10 hours. Your needs may vary.
The problem is also addressed by using refresh tokens. Your access token has a short life and is verified by signature. The refresh token has a longer life and is used to get new access tokens.
When the refresh token is used to get a new access token, that is a good time to do extra checks: has the refresh token been revoked? Is this user account still valid?
Both tokens can be stored in secure cookies and supplied on every request. Doing this allows your server to transparently use the refresh token when needed and set new access tokens in cookie responses.
This is the approach we've taken for Express-Stormpath and is documented in our Authentication section of the documentation. If you'd like to offload your authentication layer, I'd suggest Stormpath. (Disclaimer: I work there, and wrote that module).