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.
Related
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
I want to develop an Android application in which anonymous users can send requests to my server through HTTPS. I need to make sure that the requests are coming from my app since anyone can craft an HTPP request and send it. This is very critical in my app.
I read about GCM tokens, but I don't know if they can help me in my issue.
Is there a way to authenticate the requests (coming from the app) without hiding secret keys in code (because I read that hiding secrets is a bad practice as de-compilation is very trivial in Android).
Thanks
You can always generate a unique token for your user. And add that token in the header of your request and verify it on your backend.
Your server could generate unique PIN for each user of your app and it is then sent to your app and displayed over the app.
Users, even though anonymous, are supposed to enter the same PIN before sending the response. In turn request could carry this PIN that server can verify that indeed it has come from the same app.
Further you can set timeout for validity of each PIN is valid so that it is not mis-used and always latest PIN generated are used at the end of any session.
One question further to be answered related to point 1: Is how to ensure that this PIN is sent to your app and not to any fake app.
Answer to that will be : For this every app will get unique applicationid when installed on android device. While installation, this applicationid could register with your server in a discreet manner. So this way you ensure that all your API calls are coming from registered app.
I figured out how to solve this issue after following this guide: https://android-developers.googleblog.com/2013/01/verifying-back-end-calls-from-android.html
Basically, You use the GoogleAuthUtil class, available through Google Play services, to retrieve a string called an “ID Token”. You send the token to your back end and your back end can use it to quickly and cheaply verify which app sent it and who was using the app.
When your server receives the token from your Android app, it’s really important that you verify it. This requires two steps:
Verify that it’s really signed by Google.
Verify that it’s really meant for you.
Thanks.
For a quick project for a hack week me and my team implemented Google Sign-In as registration/authentication for users. The way it works:
User signs in with SDK on client (Android + iOS) and requests access_token
Client receives acces_token and uses that token for each network request to the backend as a query parameter
Our backend does not interact with google services on users behalf
The problem I'm facing is that the provided access_token returned by the google SDK is short-lived (60 minutes). That basically leads me to two questions/problems:
Is the short-living access_token even meant to be used that way?
I am used to another flow where you just use that returned token by google or any other auth provider to authenticate with your backend and then use your own authentication mechanism (probably token based as well).
If I am wrong about 1. then what is a good practise to refresh the token on the client side as it expires every 60 minutes. The way I understand it is that Google SDK starts an activity for result to sign in and I would rather want to handle all the networking in my data layer without context. Do I check the validity of that token before I request the backend every time or do I start some kind of refreshing after I get a 401 response back or something similar?
I am somewhat new in that space and I had quite some discussion about what is right and wrong with the backend guy in our team. I'm thinking number one is right, he says number two. I might be terribly wrong here. Some nice input or resources would be awesome as all the documentation online just don't answer both of those questions.
Do one thing use your google provided access token to generate a new access token in your backend and send this token on login/signup to client. Now your every request will use this token to identify users and keep track of everything.
This will not expire too. I used this in my app and it works flawlessly.
I wished to understand the facebook refresh cycle for the long term access token (60 days).
Although their doc implies
If I make a graph '/me' call a day after obtaining the access token, the token expiry would be updated or extended
but the same isn't the case. I tried querying the /me endpoint via their android SDK but the token expiry wasn't updated.
I came across a similar question Facebook: refresh AccessToken on Android but the suggestion didn't work for me.
Ps: Would be happy to share code but I doubt that is needed.
-------EDIT------
My use case involves only authentication at the client end , followed up with submitting the token to my server. This token is periodically used by my server to fetch updated user info. In order to accomplish this I need to ensure that the token never expires at the client. I don't wish to relogin the user on token expiry as far as possible.
The first line in the document you linked states:
Facebook's official SDKs manage the lifetime of tokens for you. When
using iOS, Android or our JavaScript SDK, the SDK will handle making
sure that tokens are refreshed before they expire.
If you read through the documentation, you can see that if the user uses the app, the SDK will refresh your token daily. If the user has not used it in 60 days, then he has to log in again to get a new token.
Altogether, no action is required on your side for refreshing the token manually.
Why do you think you have to refresh the token?
I've been doing a lot of search about secure my api for mobile apps for Android or IOS.
Almost all examples tell user provides an user id and password somehow in a exchange for a token.
But how to prevent someone else to consume my api without my consent?
Face the following scenario:
I expose an API,
I develop, then, an app for android to consume it,
I develop, then, an app for IOS to consume it.
Other developer performs a rev. engineer in my app, creates his own app and starts to consume it without authorization.
How to prevent that?
Short answer: you can't.
Little longer answer: If you know what you are doing you can always reverse engineer a given application and use its api. You can only make it more difficult and time consuming, using authentification via tokens and device ids or usernames is a good first step. Apart from that: why would you want to close your api to outsiders? If your server code is written well there is nothing to worry about.
You can maybe secure your API on a legal basis and sue developers who use it, but that is a completely different topic.
Some clarification regarding securing the API and securing content via the API. Assume you create a server where you can send user/password and receive a token if that combination was correct. For the account-page you send said token over and the server verifys that that token is valid and returns your account page. You secured the actual content of the API. That is obviously very possible and almost a must-have unless you have no user-specific data. But still everybody can send the exact same initial request from their custom app, sending a user/pass and again receive a token, etc. You cannot really prevent the request itself or even determine that it was not send by some service not authorized by you. You can send some hashes along the request to add some security by obfuscation, but since your app has to compute them, so can the reverse engineer.
Yes, login api are open but they return a token only on successful match in your database. You should focus more on security of your data than unknown hits at your api.
SignUp API can be used for creating a user, and login for returning token of that user. Only if malicious developer has credentials, then he can access tokens and auth APIs. There is also something about DDOS attacks so you can maybe write logic to temporarily block IPs where hits frequency is high.
You can also store device ID of signing user, which seems idle for your scenario. Entertain hits from that deviceID only. Similarly, user can add more devices with their credentials. I think even Google does that (generate alerts if user creds are signed in from new device and add the device to list if user confirms). Hope this helps.