In the coming months, Google will no longer allow OAuth requests in embedded browsers. In our projects we are using Awesomium as a web component and I actually do not know If this change will also affect our services. Google says:
Starting October 20, 2016, we will prevent new OAuth clients from
using web-views on platforms with a viable alternative, and will phase
in user-facing notices for existing OAuth clients.
Now I do not see any user-facing notices. Could anyone tell me how them looks like? How can I test my services if they are ready?
Currently we're only seeing them in iOS embedded views on Google's "consent page." The consent page is where you have accept the application's request to access your Google user information.
The blog post you cited above has been updated to say, "On March 1, 2017 we will post the same notification on the Android consent page."
We've been able to simulate it internally by spoofing the user-agent from the web views.
FWIW, the page also indicates this is going to break for macOS and Windows applications too, but there's no indication of any dates for messaging.
Here's a sample image of the messaging:
Related
I'm not sure there is a "proper" way, but before I just bodge together my own incompatible implementation, perhaps there's something in all the standards that can fit my need?
Here's the situation: Apple has declared that apps on their phones MUST include all standard functionality inside themselves. No more iframes with web content! If you need to show stuff from web, open the system browser (Safari)! Unfortunately we need to display stuff from web, so here we go...
Now, the app requires authentication which the user has done previously. We store whatever tokens we need. When the time comes to open the browser, we don't want to force the user to re-authenticate. We need to somehow pass the access credentials to the browser, and preferably do this securely. Furthermore, the webpage in the browser will need a token obtained from our OpenID Connect server.
Unfortunately, the only point of communication between the app and the browser is the URL, so everything that we give will be there, in plain sight. I know that OAuth was pretty worried about this, so much so that they made it impossible to intercept authentication with just the stuff visible on the screen and instead using things like single-use intermediary codes, backchannels and PKCE.
Unfortunately I cannot see any way to use the default flows "out of the box" to achieve what I need. I can think of modifications to those flows that would do it, but I'm not a security expert so I'd rather go with something standard which is vetted by experts.
SCENARIO
It's a good question since many companies want to show existing web content in a secured manner within a mobile app, and to avoid an extra login.
WEB + MOBILE INTEGRATED SOLUTION VIA DISCONNECTED BROWSER?
Ideally what you want to do is pass the mobile app's JWT to the external web content in an HTTP header. iOS APIs such as openURL may not support this however.
You may have to pass a JWT in a query string, in which case I would try to follow a signed request model, though it is not trivial. I have used SalesForce signed requests though not implemented a full solution myself.
Mobile app calls an API method at POST /api/encrypt-token
API returns an encrypted payload that includes the JWT
Mobile app opens a web page at https://mywebapp?token=0a78904cwdu
Web UI calls POST /api/decrypt-token to get the JWT
Web UI stores the token in memory and uses it to call the API
You will want to prevent raw tokens being written to web server logs.
I believe the recommendation for this type pf solution is to use a one time key, as described in the above link. And of course the web session will have some limitations such as silent token renewal not working.
WEB + MOBILE INTEGRATED SOLUTION VIA WKWEBVIEW
In the past I've managed secured web content in a mobile app by making the Web UI get access tokens from the mobile app. This enables an integrated UX and you can use a 'standard as possible' OAuth solution.
When the Web UI runs within a mobile app's web views it no longer does its own OAuth handling and instead calls the mobile app to get tokens and trigger logins
This means there is a single login across web and mobile views, and the Web View gets all the benefits of mobile user experience, such as secure storage of tokens
The Web UI is no longer impacted by things like the web view aggressively dropping cookies
VALID USE OF WEB VIEWS?
Web views are probably not a good long term solution in most cases. I know that Apple are likely to reject apps in 2020 if they use any of these behaviours:
Use of UIWebView - the Cordova default - you need to update to WKWebView
Delivering an app that is solely a repackaged web site with no mobile views
Displaying web content of a dubious nature (ads etc)
I suspect that use of WKWebView used responsibly and justifiably would be accepted. I could be wrong though, so please don't take my word for it.
ONLINE SAMPLES
I will be documenting some stuff about mobile / web integration on my OAuth blog, including code samples.
We are facing the below screen when trying to authenticate to Google. The app that we are trying to authenticate is used for internal development and we did not publish it to our users.
Any idea why this occurs?
We faced an Unverified App screen before (as below) but now the authentication is disabled.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Review is not required if you are only using it under the same account as created the project in Google Developer console. You can read more about this change in this help center article.
This change applies to Google OAuth web clients, including those used by all Apps Script projects. By verifying your app with Google, you can remove the unverified app screen from your authorization flow and give your users confidence that your app is non-malicious.
Once you have applied for verification it takes around a week and it should start working.
I found this thread some time ago when this happened to us in our development project on Google Cloud Platform.
You can use a project for development without verification. No problem on that. But there are some limitations (more information here and here). Basically, we reached the limit of 100 users accessing the application. It was strange because we were testing with few accounts (5-6) until we found that, if you uninstall and install the application again, it counts as a new user. We were testing incremental authorization, so we uninstalled/installed the application a lot of times and we reached the quota.
When you reach this limit, you will see the message "Sign in with Google temporarily disabled for this app" and only users from the organization where the project is hosted can access the application. So we couldn't make test with our accounts from a demo domain or our Gmail accounts.
The only solution available was to pass the OAuth verification form (even if you didn't want to publish the application), but there were problems to do it. For example, it was mandatory to remove http://localhost from valid OAuth URLs. And more problems related with development.
âť— But this has changed recently. I have accessed to OAuth credentials screen in Google Cloud Platform (APIs & Services > Credentials > OAuth consent screen) during this week and now the page it's different. Now you don't need to specify "Authorised JavaScript origins" and "Authorised redirect URIs", you just need to specify your scopes for Google APIs and the Authorised domains. Then, at the bottom of the page you will find the button "Submit Verification" and the process will start. You will also find some information on the right:
About the consent screen
The consent screen tells your users who is requesting access to their data and what kind of data you're asking to
access.
OAuth Developer Verification
To protect you and your users, your
consent screen may need to be verified by Google. Without
verification, your users will see an additional page indicating that
your app is not verified by Google.
Verification is required if
Your application type is public, and You
add a sensitive scope Verification may take several days to complete.
You will receive email updates as it's processed.
Saving without publishing
Even though your consent screen is
unpublished, you can still test your application with users with the
following limitations:
Sensitive scopes are limited to 100 grant requests before verification
is required
Users see an additional page indicating that your app is
not verified by Google.
To include "Authorised Javascript Origins" and Authorised redirect URIs" you need to go to APIs & Services > Credentials and there click on your OAuth 2.0 client ID. There will be a form where you can add them.
In our case it took 1 day to get a response from Google. In the email there were some instructions to pass the verification. We had to reply the email with a video uploaded on YouTube addressing the following points:
How does user sign-up on your app and grants access to the sensitive scopes requested in verification?
OAuth consent screen as seen by end users
How does your application use the requested scopes to provide services to developers?
A test account email and the password for us to test the user sign-up process and validate the project's functionality.
We recorded a video showing points 1, 2 and 3 and sent them a test account for number 4.
After 1 day, we got another response from Google confirming that our project had been verified.
So finally the problem was solved! 🙂
I hope this could help people in the same situation. It was really annoying for us.
I had to go into my Google Apps Script settings and turn on the "Google Apps Script API" setting. Then I tried again, and the script executed correctly without issue.
I had used the script a couple of weeks ago and it worked fine, so something must have happened between then and now that changed it... Not sure what caused that setting to switch.
I've added kGTLRAuthScopeDrive scope to OIDAuthorizationRequest and I am facing the issue shown in the picture below:
How can I verify my ios app?
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Add-ons, web apps, and other deployments (such as apps that use the Apps Script API) may need verification.
You must apply to have your application verified by google before others will be able to use it. Verify
By clicking advanced you should be able to login yourself as the developer who created it. this is used for testing only
In reference to: https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
In this page, it is clearly stated that: "On April 20, 2017, we will start blocking OAuth requests using web-views for all OAuth clients on platforms where viable alternatives exist."
Does this affect Electron WebViews as well? If it does, can you point me to any samples?
It looks like Google is indeed deprecating Electron WebViews. There are multiple solutions to this:
Open google sign-in page in user's browser and :
(1) Setup a HttpListener similar to this https://github.com/googlesamples/oauth-apps-for-windows/tree/master/OAuthDesktopApp
(2) Specify custom URI scheme in the redirect_url to open your app after login. (This might open notifications/popus in the user's browser)
Use AppAuth to perform login to Google
I set up a project on my main domain example.com and then moved it to a subdomain sub.example.com
Now when I try to use the same (default ASP.NET MVC or on my Discourse forum) project with OpenId and click on the Google button to log in with my Google account it throws the following error -
That’s an error.
OpenID auth request contains an unregistered domain: http://sub.example.com
I have tried Googling that message but apparently I am one of the first four people to see it. Any ideas here?
According to this page,
Google closed registration to new OpenID 2.0 clients in May 2014 and will be shutting down the OpenID 2.0 service in April 2015.
The reason why some hosts work and some don't is that although Google isn't adding new hosts, you can still use the ones that are already registered.
UPDATE :
Some people have asked for a simple explanation for how to fix this, or otherwise how to proceed.
Basically, you now have 2 options.
Use OAuth 2.0 (instead of openID protocols and older versions of OAuth)
or
Use Google+ login (which Google tried to "push" you towards)
For more details check the migration guide :
https://developers.google.com/+/api/auth-migration#userinfo
I would like to add some context to this thread together with a potential solution to developers that are currently blocked.
Back in February we announced the deprecation of OpenID 2.0 (OID2) scheduled for April 2015. We also announced that new OID2 relying parties (RPs) registrations†will no longer be accepted after April 2014.
Given that the API will be shut-down in less than a year’s time, our intention is to avoid having new RPs integrating with Google's OID2 API. Instead, we suggest to use our OpenID Connect API which we consider more secure and easier to implement.
Registrations were effectively closed on May 19th (as documented in the Google’s OID2 developer documentation). All RPs already using OID2 should not be affected by this the closure.
As for developers currently working on an integration with our OID2 API (presumably because they missed the announcement and warnings in our OID2 documentation), we will do our best to minimize the friction caused by the registration closure. If you are in such situation, please let us know by posting a registration request before June 15th. The post should contain a sample OID2 request used by your application, in case you prefer not to disclose such information, please post an email address and we will reach out. We plan to look into each case and try to get you unblocked in the best possible way.
†OID2 does not have a registration procedure for RPs integrating with an identity provider. RPs are associated to the realm value (e.g., www.example.com) used when contacting Google OID2 API. Thus, a RP is considered "registered" if its realm value has been used to contact our OID2 API.
You can easily change to OAuth 2, this article shows you how to register your app with Google and add the key to MVC. Scroll down to: "Creating a Google app for OAuth 2 and connecting the app to the project."
And you may need to add the Microsoft.Owin.Security.Google package via NuGet.
I had the identical problem but when using nodejs / expressjs
I have migrate my code using below url code and fixed that issue
Passport strategies for authenticating with Google using OAuth 1.0a and OAuth 2.0.
https://github.com/jaredhanson/passport-google-oauth
The sub-domains that fail are those that had never seen any user requests before. As per https://developers.google.com/+/api/auth-migration#timetable, Google is not allowing new domains in the OpenID2 API.
I have this exact problem, we use googles login to run a platform, its a brand new problem.
A few things I have discovered if this helps
Full domains trying to use openID never fail www.example.org and www.example2.com are not having this problem
Subdomains on the platform have this problem sometimes, but the same subdomains always fail and the others always work.
It started around Monday and is still happening now.
Take a deep breath and just change Startup.Auth.cs file
app.UseGoogleAuthentication();
to
app.UseGoogleAuthentication(
clientId: "000-000.apps.googleusercontent.com",
clientSecret: "00000000000");
refer to the http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on page.