We have C# on server side, and mobile apps, on server side we have set refresh token expiration time to be 30 days,
"AbsoluteRefreshTokenLifetime": 2592000
On mobile side, every time when we open the app, because we have only stored refresh token, and because access token is empty, we send a call which returns 401 and after that we are refreshing our tokens and continue with new ones, and after 30 days when refresh token expires, we show dialog that session has been expired, and send users to login screen, to make a new login request.
But recently we have started to get feedbacks from mobile clients that they have started to see that session expired dialog earler then 30 days, just about 13-14 days.
Is it possible that because we are requesting new refresh tokens every time when app is opened, some day, server revokes all takens making them invalid?
What else can be the reason of this issue?
Could be refresh token usage setting,
RefreshTokenUsage setting - OneTime vs ReUse
According to identity server documentation, a refresh token can be one time use or reusable.
If it's reusable (ReUse), same refresh token will be valid for token refreshing (till it get expires).
But if its one time (OneTime) use, refresh token get invalidated as soon as you use it.
Now in the latter case, your application must do token refresh in a thread safe manner. There shouldn't be race conditions so that a refresh call would use old/used refresh token. So check this setting as well as check for race conditions
is there any tool which can be used to understand expiration time for refresh token and to read other info
Identity providers do not allow that (at least the ones I have seen). Refresh token settings are controlled by identity server configurations. So check deployment settings. For example, it could be a configuration issue related to AbsoluteRefreshTokenLifetime and SlidingRefreshTokenLifetime as mentioned in documentation
Related
Once user login to my Fire TV/Android TV app, they have a 4-hour login session. Neither the Fire TV nor the Android TV remote has an exit button. Users usually press the "home" button to minimize the app to access other applications they installed. In such a scenario, suppose a user access the app and then minimizes the app after using it for a couple of hours. And when the user re-opens the app again after another hour, they will see the screen where they left off before. In such a case, how can I extend their login session while the user remains active within the app without having them log in again?
Currently, my API server generates a token when user login to the app, and there is another API running every 30 seconds to check if that token was expired.
The onResume method of your Activity will be triggered whenever the Activity is brought to the foreground and ready for user input, so you can check the token there, but it sounds like this is less an Android problem and more an architecture issue.
there is another API running every 30 seconds to check if that token was expired.
I highly recommend not doing this. The standard way of handling this is that when the user signs in, they get a long-lived token tied to that specific device. That token is used to fetch a short-lived token (such as your current 4-hour one). Other than the token refresh, all API requests should be made with the short-lived token.
The server should validate every short lived token that comes in and return a 4xx error if the token is expired. The app should listen to the 4xx errors and automatically fetch a new short-lived token (via the long-lived token) when it's expired. To make things smarter, you can also add code to check prior to that (e.g., attempt to get a new token after 3 hours and retry with exponential backoff).
This means you don't waste hundreds of background checks on the token when they're not necessary, any compromise of the short-lived token means the device/user is only at risk for a few hours, and you can provide the ability for the user to remotely log a device out (revoke the long-lived and short-lived token).
There are a lot of variations of this pattern, but the most known one is probably OAuth 2.0, so you could read up on that to better understand the idea. For that one, the short-lived token is the "access token" (it lets you access the API content) and the long-lived token is the "refresh token" (it lets you refresh the access token).
I am working on an app, where it requires only one active session for a single user, irrespective of the device he logs in. I have not yet coded for this but I am looking to know if I am heading in the right direction OR is there a better way to handle this
This application will be always connected to the internet so there's no offline mode and hence here's my approach to handle the single session case
On calling the login service from DeviceA, the server will maintain a sessionId.
If the user does a login from any other device (DeviceB), then the server will check if it's from DeviceA with DeviceA_sessionID? and if not it will send a 400 BadRequest response to the DeviceB with a message "Please logout from all the device you are logged in to use the app"
SessionId on the server can be valid for 2 days or a week.
The main problem I am trying to solve here is that I don't want to have any device oriented dependencies, because the vendorId or any Id can change when we do a factory reset or reinstall the app or purchase a new device.
On step number 2, I am thinking will it be a good idea to just terminate the DeviceA session and allow the login into DeviceB with a new session Id and then show a message on DeviceA that your session has been terminated? Or just wait till the session expires?
With the help of sessionIds on the server, I can make sure that the server has the logic to determine that at a time only one device session per user is active and any other sessions are just terminated.
Also, users change their devices so I assume with sessionId the user can still login and have a new sessionId created for its new device and the server can terminate the old ones.
Let me know if this is a valid approach or is there a better way to handle this case.
If you have any kind of authorization and device B is allowed to interrupt device's A session, you can refresh authorization token every request. So then right after new auth, the previous device's session will expire.
For example you can use JWT Authorization token. More here.
How I got this resolved was by using sessions and not JWT. The motivation to not use JWT was we were not implementing/using any claims here to communicate with the server for anything.
Also when you login from a different device we wanted the old tokens to be invalidated and sessions can be invalidated by the server easily whereas the stateless nature of JWT does not allow us to do that and the token will be valid until it is expired.
In Android API, access token can be re-issued through refresh token.
Even after new access token is issued, the previous one is still valid for expire time(maybe 1 hour).
I am wondering if it is ok to request a new access token everytime I need regardless of how many access token is issued so that I don't mind if the access token is expired or not.
With my simple test, It seems OK. However, I am not sure it is still OK with production service.
Any expected issue, if I request a considerable amount of access token with a refresh token?
Otherwise, should I re-use access token until it is expired?
So I want to create a backend that allows for indefinite persistent login for my Android app (like Facebook, Twitter, etc.) As such, I store a hash of the user's refresh token in my database and compare it to the client's refresh token every time a refresh is requested. If a client logs out, it sends a "api/logout" request which removes the refresh token. However, there's an edge case where if the user deletes the app without logging out, I have no way of revoking their refresh token from the database, so it sits their as stale data forever. Is there any way to deal with this case?
I solved this issue by adding a "logout" API that the client queues on log-out, which deletes the client's refresh token, and as well as a cron-job that runs every month that deletes refresh tokens that haven't been touched in 1 year+.
I get an Access Token & a Refresh Token from an Android App using a Post Request, i have read somewhere that the Refresh Token never expire & then i've seen that there is a Limit of 25 Refresh Token issued,
What is the meaning of this in the Google Developer Doc :
"Note: Save refresh tokens in secure long-term storage and continue to use them >as long as they remain valid. Limits apply to the number of refresh tokens that >are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens >to go over one of the limits, older refresh tokens stop working."
Limit apply to Refresh Token > Get Access Token Operation ?
Limit apply to Prompt User > Get Refresh Token Operation ?
That's mean a user could use the Google Api on 25 Device Max. ? & what if the user use the same Account on +25 Devices ?
I Plan to have a Background Service which once started, will automatically get an Access Token using the Refresh Token saved to ensure to have always a valid Token,
Thanks for your Clarification
If you continue reading the Token Expiration section of this Google OAuth2 document, you can see the answer you need. Google indicates a few key things to consider in your application's architecture:
Refresh tokens are issued per client + user. This means for a given app, each user per client they can be issued 25 refresh tokens.
Limit the number of clients you authorize to 15 or 20 within your application code to prevent dropping refresh tokens previously issued for that particular client-user (oldest dropping off first)
Refresh tokens begin to drop off the tail end of available refresh tokens for a given client once the threshold of 25 has been exceeded
The threshold does not apply to service accounts, which you may wish to use for a backend application which does not have a client-facing UI. These are typically server-side ONLY applications which automate processes such as: data transfer, data sync/reconciliation, etc...
I would review the examples and documentation for your use case which are provided in the link above to better understand how to solve the problem for the appropriate app type: web server, client-side, or installed.
Additionally, I would highly recommend using one if their Client Libraries (available at the bottom of the page in the link above) since that should help to simply implementation.
This is not a problem. If a refresh token is not used for six months, it will become invalid, but using your refresh token to get a new access token can be done indefinitely, in theory.
This is the main problem. If you store the refresh token on the device of your users, and a user has 26 devices for some reason, the refresh token on the first device will become invalid once you get the 26th one.
In closing, it is good to have some fallback code for when a refresh token stops working for some reason, and re-prompt the user. The user might not use the device for six months, he might revoke the app's access or it might stop working for any other reason.