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.
Related
I am trying to find a solution to the following:
Requirments
There is exists an app that allows users to add integration providers
These integration providers use oath 2.0 authorization to secure their data
The app needs the ability to have a backend job fetch data on-behalf of the user once per day
The data fetched is ingested and merged into a report that is compiled on the app for the user
Problem
User Delegated Access Token from Backend Job - I'm having trouble finding the solution that allows me to have a valid access token that is on behalf of the user without having to generate the access token from the app side
What I have tried
Refresh Token - I have tried the approach of using the refresh token to constantly get a new access token but this solution is fragile in the sense that there might be a situation that a new token is not generated in time or for some reason the user still needs to reauthenticate the connection to the provider
Automated Browser Flows - I have tried automating the user's authentication flow from the backend using saved credentials given in the app. This approach is just sketchy, costly, and would require a lot of work on the user agreement side ensuring that is being done on the backend has been consented by the user which essentially reinvents the wheel on user consent which the identity providers should have already been handling
We can use JWT for this. By doing it with JWT we'll create a token and save to the database and on every request it will decrypt the token and get the required data from the token.
Link- https://jwt.io/
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?
I would like to create an app in which there is a mobile (Android) client which uses REST API from the server. A user has to login with Facebook account (using Facebook SDK's LoginButton); on success this should create a user account on the server at the first log in.
I've already read a lot of tutorials about how to secure HTTP API using SSL and access tokens, but there is one point which I don't get. The flow should look like this:
a user log in on the Android app with the Facebook LoginButton
in the Android app I receive an access token on successful log in which I can push to the server
I can validate this access token against Graph API
if validation in 3. is succesful I can create a user account on the server
all other calls to my server API can be secured with received access token or other token which would be created by me
but what about the 2. point? I have to expose API call which takes an access token and creates an account. This API call won't be secured, so if someone calls it with stolen/properly fabricated access token, then I will create an account which shouldn't exist. How to solve this? Do I have to assume that if my create account API is called with an access token which is valid (because I validate it in 3.) then everything is ok? Is there a better solution?
You are right, never trust the client. Always validate all client input again on the server.
In your case, you're validation of the token on the server in Step 3 should include comparing the result from Graph API with the result from decrypting the user info from the token. If both match, then proceed.
There are several code examples on Facebook website on how to do this correctly. They are available in several server languages (e.g. PHP) so I recommend reviewing them.
I am creating an app and want to use the google accounts on the Android phone to get the user's email, name and possibly phone number. How can I securely communicate with a rails server? I could send the auth token but my understanding is that it changes often. I plan on making a private API token for very basic auth but I need a user specific authentication as well. I thought about using an email hash and sending that but there has to be a better solution.
Normally what I would do if the account logins were on the server is login and send a token back and check that token to the database every request but can't do that since I login on the client side.
What would be my best bet to implement something where I log in on the android side but store info on the server?
This is my answer... Uses Google Play API to get a token and verify on server/client side.
http://android-developers.blogspot.com/2013/01/verifying-back-end-calls-from-android.html
I'm trying Google Plus sign-in in an Android app (with backend support).
I could get access token and email from the user, but know I don't know how should I recognise this user from the server. I'm sending this to the server (email and oauth token) with a POST throught SSL
Of course I could recognise them with their email, but that would open the doors for everyone how knows another email that's on the database.
How could I verify that the user's correctly authenticated and has sent me the correct oauth token for this email?
Thanks!
Two thoughts:
1) Generally, you shouldn't be sending the auth token over the wire if you can help it. Instead you should be using a hybrid flow where the client gets a one time code when it authenticates, passes you this one time code, and you can redeem this for an auth token and a refresh token. Using this method, your server also has offline access on behalf of the user. See https://developers.google.com/+/web/signin/server-side-flow for details. However, I'm not entirely sure how this works with the Android library.
2) Regardless of (1), generally what you can do is to use the plus.people.get method on the server with the userID of "me" to get the user's userID and verify this against what you're expecting. See https://developers.google.com/+/api/latest/people/get for more details.
Yours is a perfect case to use the Authorization code flow.
See this link. It has some workflow diagrams that you might want to see. In your case the user should authenticate and receive an authorization code (and not a token!).
He would then send the authorization code to your server, you can exchange this code for access + refresh tokens. Have your client registered for the scope and have the client credentials.
The access token flow (called the implicit grant flow) is generally used when requests need to be sent directly from the user's browser.
And, as #Prisoner already mentioned, you will have offline access too. That would be a much better design.
EDIT - you might also want to take a look at What is the difference between the 2 workflows? When to use Authorization Code flow?