Proper way to authenticate with a backend server

Question

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) ?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.