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?
Related
I am building a hybrid app on React Native, We are using Django rest framework on the backend. We are using JWT for securing the app, the use case of the app involves storing sensitive information.
The problem is in JWT expiry. I need to hit an API with the accessToken to get a new token, this works fine and token won't expire if the user opens app every day, which is next to impossible.
Hence the user logs out every few days since by the time he opens the app the token is expired. Is there a better way to handle this? Facebook app, google pay app never log out the user.
I tried keeping a variable associated with a user suggesting he is a mobile app user and thus never expiring that token unless he logs out or done so explicitly, but I've had reviews that's a dangerous method.
You should not use access_token to get a new one!
The proper way is to give a refresh_token to the user each time you issue an access_token.
refresh_token is a long-lived one-time use token which is used to get a new access_token.
You can search to learn more about refresh_token.
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 am writing an Android app with a Google Cloud Endpoints backend, and I want to restrict my backend with a Google signin.
I have followed the Android instructions, and have successfully logged in. In other words, I have received a token, which I can then pass to the server and verify the user it stands for. Great.
However, I am missing the bigger picture here. Questions:
Am I supposed to be sending this token with each request back to the server, and repeat the process of verifying it in each request?
If yes, the token will expire at some point (1 hour I believe). I suppose the user does not have to login again, there should be away to avoid this, right?
Is a way to refresh the token (I think Google Signin is OAuth2)?
And most importantly, is all this the standard way someone uses Google signin to protect their backend? I was expecting this to be very straightforward process, since I am only using Google products. However, I am finding myself lost in pages and pages of documentation on Android and Cloud Enpoints with pieces of the puzzle.
Any help or insight is appreciated.
I have not used android authentication but google uses outh2 for all its authentication. Google SDKs may help you alleviate some of the pain of using oauth2. To answer your questions
Yes - You are in the world of token based authentication and you do send the token with every request.
Yes. token will expire after an hour. To get around this when you first do an oauth2 authentication, you also get a refresh token. When the token of the user expires you use the refresh token to get the new token. This refresh token can be stored on the client side. Client will find during one of its requests that that existing token is expired and would request for a new token using refresh token
Yes you use the google refresh token URL to use the refresh token and get the new token. I have given the important oauth URLs of google below.
This is indeed oauth2 process my friend.
since you are using cloud endpoint I believe that you would be making the authentication endpoints.
You generally make the following endpoints when doing oauth2 authentication using a service provider(google, facebook, github, etc):
https://webiste.com/auth/signin/{provider}
https://webiste.com/auth/callback/{provider}
https://webiste.com/auth/refresh/{provider}
Following are the google URLs for oauth2 that you would use:
oauth_url: 'https://accounts.google.com/o/oauth2/v2/auth', //start auth
token_url: 'https://accounts.google.com/o/oauth2/token', //get id_token, access_token, refresh_token token
refresh_token_url : 'https://www.googleapis.com/oauth2/v4/token',
token_info_url: 'https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=', //validate token
You would also want to go through google's oauth2 documentation at https://developers.google.com/identity/protocols/OAuth2.
I think you should Firebase UI Android Library for Authentication. It provides you with Google, Facebook, Email, Twitter and Github signin options and good part is that it can be done by writing only few lines of code.
For more information click here.
It's best practice to use 3ed party code to do this. It will take much less time, will have much less bugs and will be very easy to expand to other methods later.
I would recommend Firebase because it's very easy, free, works well and owned by Google.
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 am getting into Android development for the first time and am having a blast, of course. I do have a question, though, about the general approach to authentication (for dealing with a backend).
To begin, here is, in a nut shell, what I have worked out.
Using google's documentation (link), I authenticate the user using the google sign in api. I have put the logic mentioned in the reference in my app's main activity. After the onConnected method fires, I have a successfully connected GoogleApiClient.
With the now connected GoogleApiClient, I use a call to GoogleAuthUtil.getToken to get an oath2 token that I use to authenticate requests to my backend. Basically, any time I make an HTTP request to my backend, I include this token as a header. My backend reads this token and uses the Python API google provides for verifying this token. In the backend, I use the email that is embedded in the (now parsed) token to make sure the user to whom that oauth2 token was issued is, in fact, a user of my system.
Now, here are the questions. First, does this sound like a reasonable approach to authentication on the Android platform? What might I be missing? What could go wrong?
The second question is a bit more direct. When I get the oauth2 token from the client app, I store it and use the same token each time an HTTP request to a secured resource is made. Eventually, of course, the token will expire. From some limited testing using the Android emulator, it seems that if I shut down the application and restart it, I am getting the same, expired token back using the GoogleAuthUtil.getToken, rather than getting a fresh token with a new expiration in the future. In my tests, I have had to restart the emulator in order to get a token with a correct expiry. Am I mistaken here? Is there something special I need to do to tell the Google API to issue me a new token? Do I need to disconnect the GoogleApiClient and reconnect it? I hope to avoid doing this in order to limit the number of activities that need to carry the callbacks required to complete this process.
Any words of wisdom here will be greatly appreciated!
after you have got your token you can use Validate Token, and if it responses with an error: 'invalid_token', you can use GoogleAuth.clearToken(Context context, String token) to clear the token and get a new token with the method you are using to get auth token.