User access the Application Client
The Application Client redirects user to Authorization Server (via user-agent/browser)
The user enter your credentials (username/password)
The Authorization Server confirms credentials and sends the AuthorizationCode (in case of Authorization Code Grant) or Access Token (in case of Implicit Grant) to the Redirect URI (in my case, custom Android Schema pointing to my app).
...
(other steps involving token exchange or access token use steps ommited)
How and when the Application Client gets any info about the user that provided their credentials (like user ID or name)??
I'm using OAuth API Secure Project (https://github.com/OAuth-Apis/apis) for my Authorization Server, and an Resource Server/API generated by Swagger code-gen.
Everything is fine with tokens requests and responses, and the Authorization Server is saving the Access Keys with info about the Authenticated Principals fine. Also have an endpoint for retrieve this info about principal: /tokenInfo, but this endpoint is for Resource Server use (need Resource Server credentials).
So my problem is only about Application Client to get user info....
I can make an endpoint in my api only to get the info about the user/principal, based on access token and /tokenInfo endpoint referred, and return to Application Client, but its strange.... I think there is a standard for that...
Can someone helpme?
If the resource server does not expose any API which returns user information, the client application cannot get user information. If such an API exists, the client application can get user information by accessing the API with an access token.
If the authorization server supports OpenID Connect, there are two standard ways to get user information. One is to request the authorization server to issue an ID token which contains user information. The other is to access UserInfo Endpoint. See OpenID Connect Core 1.0 for details.
Related
I am not able to differentiate between these two: requestIdToken and requestServerAuthCode, when we signin with google api from android device.
My requirement is to provide option for users to login in android device, and after login sync data to my server.
Server need to validate logged in user request from android device. I am thinking to use "requestIdToken".
On the server side i am using google client library to fetch user info from requestIdToken.
There is
requestIdToken (String serverClientId)
Specifies that an ID token for authenticated users is requested.
Requesting an ID token requires that the server client ID be
specified.
and there is
requestServerAuthCode (String serverClientId)
Specifies that offline access is requested. Requesting offline access
requires that the server client ID be specified.
You don't need to use requestIdToken(String) when you use this option.
When your server exchanges the code for tokens, an ID token will be
returned together (as long as you either use requestEmail() or
requestProfile() along with your configuration).
The first time you retrieve a code, a refresh_token will be granted
automatically. Subsequent requests will only return codes that can be
exchanged for access token.
From the docs.
As you can read here, requestServerAuthCode() is specifically for requesting offline access. If you do not need it, use requestIdToken()
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 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'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.
I am building an Android app for a website that uses FB connect to link their user data with FB user data by FB id. When I allow the user to log in via Facebook's Android SDK, I get an access token for which I can request data on the user's behalf. I would like to send the access token to the server and have the server then request the user's id to create a local session and send me back the user data specific to this website. Does Facebook allow the access token to be used in this way (authenticate from device and then request data from the server with the same token)? The alternative is to use the SDK on the device to get the FB user id and then pass that to the server, but I feel it's not very secure to allow a session to be created with just a FB user id. This would be an easy thing to impersonate.
What is the typical scenario for this use case (log in via Facebook SDK to create a session on your own web app where the user data is already linked)?
Yes, this is allowed by FB. See below:
https://developers.facebook.com/docs/facebook-login/access-tokens/#architecture
As noted above, access tokens are portable. This means that once you
obtain a token, you can generally use it from any machine - server,
client or otherwise.