When configuring the OAuth2 Consent Screen in the developer console preview google shows "google plus circles" and other details I'm not interested in (only the email address is required).
Is the actual consent screen the user sees configured on the backend side or is this within the scope that the client application requests with the accessToken?
How can the user consent be restricted to the bare minimum- just the email address?
As far as determining consent, the Google OAuth2 Consent Screen is only configured via the scopes. Of course you can set your client's logo, etc. in the backend but consent is determined by scopes sent in the authorization request. You can request just the "email" scope
e.g.
https://accounts.google.com/o/oauth2/v2/auth?scope=email&client_id=919088372921-uvdkhotpcvoviqasigkf7k4aaeq5uh8p.apps.googleusercontent.com&response_type=code&redirect_uri=http://localhost:9000
(enter this into a browser to see what i mean)
However, you cannot get rid of the "Know who you are on Google" consent item--even if you only request the email scope. See https://stackoverflow.com/a/24424716/1098564 for the reason.
Related
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 am having a microservice system with backend and frontend hosted on different servers. To authorize and authenticate a user in my frontend app I use 'Resource Owner Password Credentials' flow to obtain an access token (since frontent app is trusted).
Now I want to implement authorization code flow to give permissions to 3rd party apps to act on the user's behalf. To do it, I need the login page and the consent page.
In default examples for IdentityServer4 for this flow, views for login and consent pages are returned by identity server itself (and, maybe, it even use session cookies between login page and consent page).
Since my frontent app is fully trusted, how could I have login and consent screens in this app to reduce duplication?
Maybe, I could make endpoint in identity server to issue the token for the third party app, given that user has access token obtained in trusted frontend app?
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.
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