Given an API which uses token authentication (e.g., JWT), how would a client store and cache the token? To remedy the effect of stolen tokens, tokens usually expire after a certain amount of time. However, almost all applications require only to login once. How do they realize authentication? Do their tokens have no validity period or do the apps automatically apply for a new token?
You can store your token in an Account Manager on Android. Regarding token validity all apps have this tokens expire from within hours to days depending on how fast you want to change them.
There is no specific way to handle expired tokens you will have to write your own custom logic for this. Generally what a lot of apps follow is if the user's token has expired they use an api that takes the old token and if the token is not a very old like if it expired within 1 - 2 days they give back a new token but if in any case the token is historic they will logout the user and ask him to again login by providing password and username via your basic OAuth mechanism.
Related
Currenty I am using Amplify SDK for using AWS Cognito in the App.
After login i am retriving idToken which expires in about 30 min according to the doc.
So, every time idToken expires i have to make user login again to retrieve idToken.
Is there any way to get refresh idToken without making user to login again every time it expires?
I have looked into this doc but could not figure out what to do.
Using Tokens with User Pools
How are you signing in? The standard authentication will return ID, Access and Refresh tokens and the SDK will handle the refreshing of the tokens when they expire after an hour. If you are signing in through the HostedUI, you might be using implicit grant flow, which will only return ID and Access. So you will need to re-authenticate after an hour. The alternative there is to use the authorization code grant flow.
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.
What's the validity of a refresh token? From my observation, refresh tokens expire in an day and then the user has to again authenticate his/her account which is tedious and redundant. How to prevent refresh tokens from expiring or give them longevity?
According to https://developer.microsoft.com/en-us/graph/docs/authorization/app_authorization when the access token is renewed using the refresh token, both tokens are extended. Presumably, then, as long as the refresh token is never let to expire, this could go on indefinitely.
This article includes information about the default lifetimes of tokens issued by Azure AD:
https://learn.microsoft.com/en-us/azure/active-directory/active-directory-configurable-token-lifetimes
There are no defaults where refresh tokens expire in one day. They last at least 14 days minimum. You may be experiencing a different issue.
I’m implementing a Android app and that must contain a user login. To do this I create my own authenticator with the purpose of login only once. Then AccountManager can request access tokens, so the application is not handling passwords directly. The AccountManager stores the user account and the token.
I’m using JWT (Json Web Token) to authenticate the user in my REST API.
I wonder whether this flow is correct or there is a better approach to do this in Android.
Here is the flow I am currently using:
The user enter user and passwords in the login screen at first time.
I make a request to server to retrieve a valid token (JWT) that is stored in the Account Manager.
Subsequent requests use the received access token until it is expires (1 hour) to retrieve content from the API.
After the token is expired, it can be refreshed up to two weeks after issue time. From this moment, user credentials are needed to retrieve a new token.
Is this process the correct way to work with the token, and refreshing it? Is the process safe? Are there other options?
Considering this flow is not using a “refresh token” to generate a new one but the access token, what would be the best usage of the Android Account Manager? What other tools should I use? Is it recommended an Oauth2 implementation along JWT in order to implement a “refresh token”?
Cheers!
I can tell, you are on the right road of using JSON Web Tokens and reproducing it.
but the safety you mentioned is all about encrypting the token you retrieved and then saving it in Account Manager (also the same with user credentials) with some encryption method of your choice like AES or RSA and then decrypt if when you wish to use. Also using a server-generated secret key with a secret algorithm would kill the shot for any hacker.
As you understand everyone with a root access can get hands on the saved credentials database and use it.
Using these tricks will lower the need of using Oauth 2.0 which involves a refresh token.
hope it helps
According to the doc, in order to authenticate with a backend server I have to :
send the user's ID token to my server using HTTPS.
verify the integrity of the ID token and retrieve the user's ID from the sub claim of the ID token.
This work quite well, but how to do if I have to authenticate all the request to the server ?
Should I store the idToken (on a private sharred preferences) and verify it each time server side ? Since the idToken have a validity date, the client must be able to regenerate it when it has expired.
Or on the first connection, should I return a single id (without validity date) to the user which will allow him to communicate with the server (seems less secure) ?
The token should be verify with every request to the server it's like a key for each request. This key is not valid for a long time period so you have normally a refresh token if you want the "session" to be persistent. If you don't have it you will need to authenticate again every time the validity period of the token is expired.
So yes you should store the token in the client side. The best practice is to have a really short validity period to be sure that if the token is compromise the attacker will have a short time to do malicious thing.
I foud a technical answer (#EmCode's answer is correct) in the doc of the silentSignIn() method. (Here is a link).
The GoogleSignInResult will possibly contain an ID token which may be used to authenticate and identify sessions that you establish with your application servers. If you use the ID token expiry time to determine your session lifetime, you should retrieve a refreshed ID token, by calling silentSignIn prior to each API call to your application server.
See if this makes sense:
This work quite well, but how to do if I have to authenticate all the request to the server ?
I think the purpose of google sign-in is to authenticate users by their google credentials. It is not really for authenticating all your client requests against your own server. What will happens between your server and google should be only user token validation. Once the token is validated fine, the subsequent C/S data exchange can use authentication of your choice, and no need to bother google each time or care about the token validity.
If you use the ID token expiry time to determine your session lifetime, you should retrieve a refreshed ID token, by calling
silentSignIn prior to each API call to your application server.
Yes, if sessions are used your application and you want the token to define validity, then you need to bother Google all the time.
The Proper way to authenticate with a backend server is retrofit use this lib this is very fast to fetch data or upload data on beckend server.