I'm currently working with a backend service, which is allowing users to log in using the Google Games library on a client application.
The user can send us through their gplay id in order to log in, or restore an old account. Including their gplay id, the user is sending us the following;
GPlay ID: gxxxxxxxxx
GPGS client id: xxx-xxxxx.apps.googleusercontent.com
GPGS auth code: 4/xxxxxxxx
message_salt: <ByteString#xxxxxx>
Is there any way to use the above data on the server, and verify that the user owns the GPlay ID that they are sending us?
Currently, I'm not seeing any way to authenticate the user's ownership of their GPlay ID - nor am I seeing any obvious way that it can be compared against their client id or auth code to ensure that the user's request to log in/restore an account using their GPlay ID is legitimate.
Does anyone know of any way that you can verify a user with the above data?
The server auth code is the only piece of information you need to send from the client to your backend server. To use the server auth code:
Associate your client app and your backend server app to the same game definition on the Play console.
When building the Google Sign-In configuration, add the requestServerAuthCode() option, passing in the client id of your backend application.
Once the user authenticates, get the serverAuthCode from the GoogleAccount object.
Pass the authCode to your backend server.
On the server, exchange the auth code for an access token. This token is specific to your application and the user. Save the refresh token on the server in case you need to refresh the access token.
Once you have the access token, verify the token by sending a GET request to www.googleapis.com/games/v1/applications/<app_id>/verify/. This returns the information about the authenticated player.
There is a sample of both the client and server side code at
https://github.com/playgameservices/clientserverskeleton
Related
I would like to integrate PayPal signin into an android app so to authenticate the client to the Firebase Database. I've managed to create a custom funtion on the node.js server that creates tokens from the provided uid, in order to use "signin withcustomtoken" function in the client application. Should I send the uid to the nodejs server through https in order to get the token? Is there a better way?
Don't create an HTTP endpoint that accepts a uid and returns a custom token. This is a huge security vulnerability as any attacker would be able to impersonate any user knowing their uid.
What you need to do is the following:
Implement a paypal OAuth code flow. You can use third party libraries for that.
When you get the paypal OAuth authorization code, you send it to your backend, you use the paypal client ID and secret to exchange for a paypal refresh token and access token. You can then get the user info associated with that paypal user including their paypal uid. You would then mint a Firebase custom token using the Firebase Admin SDKs and return it to the client.
On the client you would signInWithCustomToken to complete sign in with that custom token.
In this case you are exposing an HTTP endpoint that takes an authorization code and returns a Firebase custom token.
This is the basic idea (details excluded). Of course you still have to ensure the flow starts and ends on the same device by passing some state and then check that you get it back in the end. You also have to ensure the auth code is returned to the correct app using something like app links, etc. Firebase Dynamic Links can be helpful there.
I'm currently working with a client-side application that's using Google Play Games Services to log in the user. We're then sending the user's google account id over to our Server, where they can log in to/restore an account using it.
The implementation on the client side is returning
GPGS client id: xxx-xxxxx.apps.googleusercontent.com
GPGS auth code: 4/xxxxxxxx
message_salt: <ByteString#xxxxxx>
Using:
(GetServerAuthCodeResult) Games.getGamesServerAuthCode(mHelper.getApiClient(), getClientId())
However, Google's server-side documentation requires an 'id token', which does not appear to be retrieved from the Games library.
Attempting to validate either the GPGS client id or GPGS auth code using either GoogleIdTokenVerifier, or through the standard web endpoint at https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=TOKEN_HERE always yields an error return, containing;
{
"error_description": "Invalid Value"
}
Is there any way we can use the GPGS client id, or GPGS auth code to verify with Google that this is the legitimate account for the Google Play ID that the user is logging in with? Or do we need to completely change the implementation on the client-side?
I'm having a hard time wrapping my head around how to authenticate a user in my REST service. I plan to use Google Sign-in (on Android, namely). I can't quite figure out how to authenticate users on my server. I do not want to have any authorizations (other than validating the identity of the user), all I want to do is when I receive a request, validate that the user is who he (or she) says he is.
My understanding is that the user will login, get some sort of token from Google, then send that token along his request to my server which I will use to validate his identity. However, from what I read, the user will encode their requests in a JWT (json web token), which I will then use to validate their identity without ever talking to the Google server directly. Did I understand properly?
On Google's documentation, it says
If you do not require offline access, you can retrieve the access token and send it to your server over a secure connection. You can obtain the access token directly using GoogleAuthUtil.getToken() by specifying the scopes without your server's OAuth 2.0 client ID.
But it does not say what the server should do with the token.
You have an android app which enables user to log in via Google+ Sign-In, and then this Android app will call your REST API. What you want is how your service authenticates this request. This Android client will send request to your service with token, and you need to validate this token for authentication. Is my understanding right?
If so, you need to validate the token sent to your service. The reference you mentioned is for Google API calls, in your case; it's your own service API call. For the Android side, just follow the reference, in your service side you can use TokenInfo validation to authenticate users.
I have an android application - service, which sends data to the server and user is identified by email and password.
As I see I could save Google ID, name, email and etc once user is logged in, but if I use just Google ID to identify user in my service that could be unsafe. right? My service use POST method to send data to the server.
So, my question - is there any way to save Google account information and use it to identify that user on my server safely?
I have developed many stateless RESTful webservices for a mobile application in Java and they are working very well.
For example:
http://.../api/coupon
http://.../api/coupon/{id}
...
Now, I have to extend these services because I have to send different data back to the mobile for every user. So I need to know on the server side which user try to get or set information. And I have to prevent the serve of unauthorized users.
There are two different way how user can login into the mobile application:
log in with facebook account
log in with an application account
I need to develop two login and a logout services because the users who use the mobile application have to login into the application.
I read lots of article about auth and RESTful and OAuth.
I think I have to develop two login services with two imput parameters: username and password.
For example:
localLogin(String username, String password) -> token
facebookLogin(String username, String password) -> token
These logon services have to generate a same token and send it back to the mobile application in the http header. And after the login process the mobile client has a token. And the client has to send this token to the server when it makes a RESTful server call.
What do you think? Is my idea good?
If it is, could you help me how can I start to develop this in Java?
If it is not, could you tell me the good way?
You do not need 2 log in procedures. Just use the Facebook SDK!!
i) In your app would be a login with facebook button.
ii) User clicks on it and is then redirected to the facebook login page, where the user enters his credentials and facebook returns a token to you. You do not have to worry about the user's facebook credentials or storing them anywhere! Facebook will handle that for you. Consider the FB login part as black box to your app - you simply make a FB SDK's login call and it will do some processes and give back a access token to your app.
iii) Now, you can exchange the access token for the user's profile information. Enter this profile info to your database - that will ensure authenticated call.
Once you have verified that the user is logged on you can do whatever you want.