Using the Google Sign In SDK, a user can sign in via OAuth2 with some default scopes requested. It can be beneficial to not request every scope an app may need up front, and instead to request additional scopes at a later time so as to not overwhelm the user at sign up.
Google outlines the process for doing this here.
The issue is that, after a user has signed in with Google, upon requesting additional scopes the user has the ability to switch Google accounts and authorize those scopes using a different account before returning to my application.
Is there a way, similar to calling -[GIDSignIn signIn], to explicitly specify which user I want to signIn and not allow the option of changing accounts?
I am not familiar with Google Sign in SDK. Most of what I have done has been written myself so I don't know how that SDK really works. However that being said the Authentication server does support something called Login_hint which should allow you to force them to use a specific user.
login_hint email address or sub identifier When your application
knows which user it is trying to authenticate, it can provide this
parameter as a hint to the Authentication Server. Passing this hint
will either pre-fill the email box on the sign-in form or select the
proper multi-login session, thereby simplifying the login flow.
More info
login_hint can be the user's email address or the sub string,
which is equivalent to the user's Google ID. If you do not provide a
login_hint and the user is currently logged in, the consent screen
includes a request for approval to release the user’s email address to
your app. (Read more at login_hint.)
If memory services Google Sign in SDK does work with openId connect so it should be possible.
Related
We have OAuth2 on our website, and according to our logs, we redirect users to URL like this:
https://accounts.google.com/o/oauth2/auth?access_type=offline&client_id=xxxx&prompt=consent&redirect_uri=xxxx/callback&response_type=code&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email&state=Y38pUwFTAqbaHsU6oa4q
The next log entry is redirect callback from Google, which is missing www.googleapis.com/auth/youtube.readonly scope:
https://ourapp.com/oauth2/callback?state=xxxx&code=xxx&scope=email%20profile%20openid%20https://www.googleapis.com/auth/userinfo.profile%20https://www.googleapis.com/auth/userinfo.email&authuser=0&prompt=consent
What may be a reason for this behavior? It happens only to some users, and very inconsistent. I wasn't able to reproduce it by myself.
The application is approved by Google and the scope usage is verified.
For apps that request more than one scope (you are asking for identity scopes email, profile and YouTube), you must be able to handle partial consent where the user may choose on the consent page to not grant access to one or more non-identity scopes.
https://developers.google.com/identity/protocols/oauth2/policies#unbundled-consent
You can encourage your users to grant access to the scope needed by separating the sign-in moment (asking for email, profile) information from the moment of asking for YouTube access. This is called incremental authorization.
You can also tell your users before you redirect to the OAuth flow why you are asking for the data you need to let them make a more informed choice.
The goal of the steps below is to create a custom oath client ID which will be used only for my instance of rclone. rclone already is registered as an app with google API with it's own set of client ID credentials, but the recommended way is create another set for the sake of performance.
In the google api developers console I create a new project called my-rclone-project.
Once the project is created I proceed to the OAuth consent screen where I choose the type External. As I proceed to the OAuth consent screen there is a setting paragraps called Scopes for Google APIs. Here I leave the default scopes (email, profile, openid) explicitly not selecting the scopes which would allow access to google drive.
I call the application my-rclone-app and use the defaults.
After that I go to the Credentials screen and do CREARTE CREDENTIALS -> OAuth client ID.
I choose the Desktop app and name the client my-rclone-desktop-client. Finishing this results in the reation of the Client ID and Client secret. Given the scope selected in the OAuth consent screen i would expect that these credentials won't allow the app to ask permision for anything besides what was defined in the scope. So it shouln't be able to ask for permission to access the google drive APIs.
I than proceed to configure the rclone from my pc rclone config. I enter the oauth credentials I created in the step above. During the config process I'm asked to define the scope to use when accessing google drive as if the OAuth consent screen isn't relevant at all. As the config nears it's end, I'm redirected to the browser where the app is requesting to See and download all your Google Drive files. I accept that end end the config with defaults selected.
As I try listing with ./rclone lsd google-drive: I get an error about the drive API not being enabled with a link in the error on how to enable it. Going on that link and enabling it results in ./rclone lsd google-drive: listing the content of my drive.
What is the purpose of having to define an OAuth consent screen and the API scope as a part of it when the app can request an arbitrary scope completly bypassing the scope selected in the OAuth consent screen setup?
Reference: Create a client ID in google API
Why you want to have custom OAuth consent page?
In order for you app to use one of Google's auth servers, your application needs some way to be identified by auth servers and that is where Client ID and Client Secret comes in to play and consent page server as a screen on which you application specific information such as application name, contact info, privacy policy, term of use etc. will be displayed to the user.
What are scopes that you define on consent screen setup?
On consent screen set up you are supposed to include all possible scopes that you application is going to request from Google APIs, but that doesn't mean you app is limited to those scopes only. Scope listed here will be used by Google for application verification purpose and once Google verifies you application, it will no longer display This app isn't verified warning page as long as your app is requesting one of those verified scopes.
Even after verification, if you application completes verification, requesting any scope access which isn't included in this list will still display This app isn't verified warning message.
and clicking on learn more link will open Google Account help page which clearly states once you provide access to application, when you allow third-party apps to access your Google Account, they can copy and save your data on their own servers. Because Google can’t protect the data on another company’s servers, your data may be subject to greater data security and privacy risks.
What is the purpose of having to define an OAuth consent screen and the API scope as a part of it when the app can request an arbitrary scope completely bypassing the scope selected in the OAuth consent screen setup?
The main purpose of the consent screen configuration is to allow app developer to present information about application it's terms and privacy policy during authorization process. And of course not to have warning once application is verified.
Please refer following link to better understand about unverified apps and scope verification:
https://support.google.com/cloud/answer/7454865?hl=en
https://support.google.com/cloud/answer/9110914
https://www.gmass.co/blog/five-annoying-issues-google-oauth-scope-verification/
https://support.google.com/accounts/answer/3466521?p=app_notverified&visit_id=637365968258169095-220403864&rd=2#notverified
I have an application that currently integrates into my merchant account using my access token. Early discussion with neighborhood merchants indicates some positive interest. I want to integrate OAuth support so that I can try to get traction with those merchants.
Though https://docs.connect.squareup.com/api/connect/v1/#navsection-oauth has information, I seek some additional clarification.
(i) Access using https redirect-url is denied at Square Connect Authorize has an answer "By default the OAuth flow is disabled for applications which is why you are seeing the "Authorization not allowed" failure. If you wish to enable OAuth flow for your application then you need to contact Square." #SquareConnectSupport: I have sent an email to Developer#Square, please let me know what else do I do.
(ii) Here is how I think it will work - the OAuth integration (Please confirm)
User types in browser say "mysnow.com/square"
The Handler at "mysnow.com/square" allows user to type in an ID this ID is local to mysnow
Then the Handler at "mysnow.com/square" directs the merchant to https://connect.squareup.com/oauth2/authorize along with my application id, permissions and redirect url.
The handler then receives a notification code with AuthZ Code at the redirect URL previously provided.
Next the handler obtains the Access token (using the AuthZ code)
Finally, the handler then saves the ID, the AuthZ code , the relevant Access Token and the date/time stamp (when the token was obtained) as a tuple in a safe data store.
(iii) Using the Access Token
When there is need to access merchant data of given ID, then use the ID to get the Access Token. Use this Access Token to manage the permitted data (based on permission)
Renew the access token periodically.
(iv) For testing purposes, I create few test/dummy merchants? Or do you have dummy merchant accounts that I can use for testing.
You can authorize up to ten merchants through the OAuth flow without approval from Square, which should be enough to get your integration running and tested. If you would like to make it more broadly available, you will need to contact Square about getting the app in the Square App Marketplace.
That looks essentially correct. The best practice for OAuth is something like this:
Merchant visits your landing page (e.g. mysnow.com/square) and clicks an action to start using your square integration.
Merchant's browser is redirected to the OAuth page (https://squareup.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&scope=LIST_OF_OAUTH_SCOPES_YOU_NEED)
Merchant authorizes your application to access their data and is redirected back to your site. In the URL is an authorization code
Your backend makes an API call to Square to exchange the authorization code for an access token. It then uses that access token to look up information about the merchant and pre-populate fields of your signup form (e.g. you can get name, email, etc)
With a partially populated signup form on your site, merchant is prompted to complete their registration with your service.
There isn't really a way to create "dummy" merchants, but you can sign up for multiple merchant accounts with the same identity information, as long as you use a different email for each one. If you have GMail, you can do "you+someword#gmail.com" and the mail will be redirected to "you#gmail.com", so you don't need to create a bunch of email accounts to have unique email addresses.
I am trying to support "Hybrid" Federated Login and oAuth2 (using logic from this document) for a webservice which will:
support Sign in using your Google account on my site. That is, from the documentation: You can also choose to use Google's authentication system as a way to outsource user authentication for your application. This can remove the need to create, maintain, and secure a username and password store.
Access the user's Google Analytics.
Here are the steps I have done.
I form my request to https://accounts.google.com/o/oauth2/auth with the scopes (Google Analytics) I want access to.
I Get redirected to google where it has my icon and which scopes I am requesting access to. I grant access.
I get redirected back to the callback page.
I get the tokens (access and refresh), as well as a huge id_token string (which I don't know) and store all of this information in my database.
I then make a call to https://www.googleapis.com/oauth2/v1/userinfo?access_token=xxxyyyzzz to get the user's email and name and store this information in my database too. I also notice it returns a id field which to my knowledge never changes and I presume is some sort of unique identifier. I store this too.
Question: If I go to Authorized Access to your Google Account section in my Google account, it shows that my site has access to "Google Analytics. BUT, it does not say Sign in using your Google account. This is what I am trying to accomplish. I would have thought using the logic would enable Sign in using your Google account. What am I doing wrong? And what would be the applicable call to google so that users can sign in to my site?
If your site has access to something like your Contacts or Analytics using OAuth, you'll never see "Sign in using your Google account". I'm pretty sure that's only if you use OpenID (not OAuth) only for sign-in.
Specifically, OAuth is used for giving you access to APIs to create/update/delete data, while OpenID is for signing in.
If you are asking how to identify user for future logins, you have two options:
Mix OAuth with OpenID, that is called Hybrid. I have described it on this answer.
Use userinfo scope and request userinfo (email, etc.) after successful OAuth authorization. It is described on Google OAuth 2 documentation.
If you mean automatically login to your web site in future visits you can use OpenID "immediate mode" (openid.mode parameter).
When the user is redirected back, you call the second request from your own (server-side?) code, and get their email address. When you successfully get it, that means that the user is logged on. You can add it to the session (e.g. as cookie), and as long as you have it, the user is logged on. You make the user log out by forgetting the email address, so by clearing the session/cookies.
Add this paramter to the https://accounts.google.com/o/oauth2/auth URL call: approval_prompt=force and then the Sign in using your Google account will always show regardless of whether the user was already signed into that or any other account.
So the call would be like this https://accounts.google.com/o/oauth2/auth?client_id=<client id>&redirect_uri=<uri>&scope=<scope>&access_type=<online or offline>&response_type=code&approval_prompt=force
Goal:
Allow a user to authentication with Facebook into an iOS application which requires access to a protected web service that I'm running.
Assumptions:
There is a native authentication (and registration) system in place for those users that opt not to use Facebook for sign in.
Details:
Assume we want to offer the option for a user to sign in with Facebook without creating a separate account/credential for our system.
Because we support our own native auth mechanism (username and password) we have our own user IDs and issue an authentication token that is used for subsequent interactions after the initial credential validation.
I'm surprised that Facebook doesn't have best practices for this in their developer documentation. All the existing documentation is either assuming you are building FB auth into a website, or a standalone mobile app with no service that requires authentication.
Here's my initial thoughts on how this would be designed but want validation on whether it's correct.
Client pops the Facebook iOS Login
UI User signs in with Facebook credentials and gets access token
iOS App passes access token to our server
Our server talks to FB graph API using access token to (a) validate the token and (b) get the FB user ID for that access token.
e.g. Our server would call https://graph.facebook.com/me/?access_token=XYZ which would return profile info in a JSON object
Assuming it's valid, our server extracts the User ID from the JSON object and checks whether the user already has an account. If so, we issue our own auth ticket to client to use for that session. If user doesn't have an account, we create a new one with the Facebook User ID, assign our own unique UserID and issue our auth ticket.
Client then passes auth ticket back on subsequent interactions that need authentication.
This seems like the right approach to me but not sure if I'm missing something insanely basic and going down the wrong (complicated) path.
I just dealt with this myself, and here's the part that bit me:
In your step 5... It's possible for a user to register for an account with you entirely separate from their Facebook ID, right? Then some other time they log in with Facebook.... And you just created them a second account and lost their first one.
There needs to be a way to be logged in to your web service, then log in to facebook, and capture the association between the facebook ID and the local account.
Apart from that, your plan sounds solid.
Update: Facebook has added a doc outlining such a scenario HERE
Use https to transmit the auth token to your server, as stated by Facebook
Sharing of Access Tokens
Our Data Policies explicitly prohibit any sharing of an Access Token
for your app with any other app. However, we do allow developers to
share Tokens between a native implementation and a server
implementation of the same App (ie. using the same App ID) as long as
the transfer takes place using HTTPS.
One problem I can see with this strategy, is that somebody can give you an access token obtained for a different facebook app. As far as I know, there's no way to verify that the access token is for your application, so you'll just go on and use it.
It doesn't sound very harmful, though. Generally people/apps try to protect the access tokens, rather than sharing them.
One possible exploit of this would be, for somebody to create their own site or mobile app, obtain access tokens for their users and try to authenticate them, using your API. If this succeeds (the user is has a facebook account in your site), the malicious site will be able to use your API impersonating the user.
It's a bit of a long shot, but I think it could work.
Edit: It looks like there is a way to validate the access token after all. See the answer by #Daaniel on question Get application id from user access token (or verify the source application for a token).
your solution totally works.
Maybe an alternative: why not just get the email on the client from the initial social service request and send to your web service? The web service could just store the email, and maybe a social_provider as well. I understand that your web service will not be able to validate where the email came from, but isn't there a high-trust relationship between your web service and your client? If there is, seems like you can depend on the email coming from the right place. Someone please let me know what obvious thing I'm missing that makes the email-based approach silly...