I have an Android App, for the login use google account using Firebase. When I launch the Android application, Firebase returns a token with user information. I sent that token to my server to validate. In the token there is a date and an expiration date (1 hour).
Client -> Android
Server -> RESTFUL PHP
From here I do not know what is safe or what is the safest way to communicate:
1st - In each https request from the client to the server send the Firebase token until it expires. (For each request I must collect the public keys provided by Google in a URL to decode the token)
2nd - When my server receives the Firebase token, it must return a new token (generated by the server) that the client must send in each https request to the server until it expires.
Which is the good way ? I am wrong and is there another better way?
The correct option is the 2nd.
Although you have to make a query to Google for each request to decode the token, the real reason is that the token generated by the server may contain other data related to the application: permissions, profile, or whatever interests us.
To generate the Token on the PHP jwt server
composer require firebase / php-jwt
Related
I have the following situation:
I have an app that will be using a subscription based payment system via the app or play store. I want to avoid implementing my own account system and verify the users via the Apple-ID or what the equivalent is on Android side, using Apple/Google Sign-in if this is possible.
The problem is that the app will have to communicate with a server every week, so that means the requests to the server need to be authenticated, that this is coming from a client (smartphone/tablet) that has an active subscription going. How do i do this the best way?
If i understand correctly then using Apple Sign-in you will get a token. Should i send this token to the server, where the server then communicates with the App Store API to verify the token on every request? Is this completely equivalent on the Android/Play store side? Or should i verify the token once on the first request, then generate my own token and send it to the client so for the rest of the session it can authenticate using that token to avoid having to go to a third party system on every call. But how do i store this self-generated token? As it needs to be linked to something on the client. Am i legally allowed to store Apple-IDs on a server?
We are developing a system where the client (mobile app) communicates with mostly with a node.js backend and sometimes with firebase directly.
One of the features is peer to peer messaging and we are using ChatSDK on the client side to integrate Firebase. We are having some difficulties understanding custom authentication with ChatSDK.
What we want is a user to be able to register and sign in (Email,Facebook, Google) using the ChatSDK. Our backend authenticates client calls using admin sdk’s verifyToken function. The token expires every hour - should client be grabbing a new token every hour? How does the refresh token come into play here?
We do have an endpoint on our server which can generate a custom token using createCustomToken(uid) function. Should the user first register with the chatSDK then use this endpoint to grab the token? Is this a security concern that all someone needs is a user’s id to grab a token to access sensitive data through HTTP endpoints?
1) How can we grab Token from the chatSDK alone?
2) How does a user ensure it always has a valid token to communicate with node.js backend?
I see some similar questions related to this question but those ones are too old to be considered, so I will ask again here.
I have an Android App that needs to authenticate to a web service to exchange data that will be stored on Google App Engine. For that, I would like to use OAuth2.0 to provide an authentication mechanism between my App and the web service as shown here: https://developers.google.com/identity/protocols/OAuth2WebServer?hl=en and here https://developers.google.com/identity/protocols/CrossClientAuth
I'm already doing a validation of the token on the web service side as shown on the documentation. The only part that I don't have clear is what to do on the GAE web service and Android after a refresh token is being obtained on Android and validated on the web service.
The questions are:
Must I exchange this token all the time for every communication
between the app and the web service? is it secure?
What is the best way to keep the communications going forward?
After researching about this, this authentication flow I'm using:
Sign in on the app as shown here: https://developers.google.com/identity/sign-in/android/sign-in
After Sign in, obtain a token.
Send the token over HTTPS to backend server
Validate the token on backend server with GoogleIdTokenVerifier verifier (you can also call the tokeninfo endpoint) as shown here: https://developers.google.com/identity/sign-in/android/backend-auth
When you receive the Token on your backend server you should:
After you receive the ID token by HTTPS POST, you must verify the integrity of the token. To verify that the token is valid, ensure that the following criteria are satisfied:
The ID token is a JWT that is properly signed with an appropriate Google public key (available in JWK or PEM format).
The value of aud in the ID token is equal to one of your app's client IDs. This check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app's backend server.
The value of iss in the ID token is equal to accounts.google.com or https://accounts.google.com.
The expiry time (exp) of the ID token has not passed.
If your authentication request specified a hosted domain, the ID token has a hd claim that matches your Google Apps hosted domain.
User authenticated. Token must be sent over on the request header for every communication with the backend server, then the backend server needs to verify it everytime.
I am trying to authenticate my app with the server using token.
when I login to my system, server sends the token and I store it in current Session/ Application instance.
Later I need to pass that token on each request along with the other data.
Could anyone please provide me a way of sending the token to server? Do I need to do anything for security for eg. encryption etc. ?
Pass your token in as Auth Header in your request header
for example
request.put("Auth","token_here");
I'm using Google+ authentication in my app to allow a user to sign in, and have access to their 'data' on my server.
The authentication process following the following steps:
User logs in using Google+ on the app, and receives an access token.
The user passes this token to the server.
The server uses this token to verify that the user is who they say they are (following the process shown here). The server can return the data as needed.
This is the part I'm stuck on - How do I verify that the user is who they say they are for future requests without making a request to Google's servers every time? Do I return a session token to the client application that is used, and regenerate the token after some amount of time?
Absolutely. Sending a session cookie is exactly the thing to do.
You will want to use ID tokens to verify that the user is who they say they are. There is a sample project in Java on Github to demonstrate this.
Also, you should be passing a one-time authorization code to your server, not access tokens. See the documentation for getting your server side tokens from an Android app. When you have that code, you send that to your backend and then exchange that one-time code for the server's own copies of access and refresh tokens for that user. Because you receive the tokens directly from Google on your backend they are more secure than having to send between mobile apps and your backend.