My captive portal allows my guest wifi to use their Google auth credentials in order to allow access to my wifi.
The portal triggers an OAuth 2.0 with Google service and get back the user profile.
Google decided to stop supporting OAuth 2.0 in Embedded browser on April 22nd 2017.
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
As far as I know, there is no way to force IOS or Android devices to start a real browser during the captive portal detection process.
I have sent emails to both oauth-help#google.com and oauth-feedback#google.com. It's been a month and no response.
I get the feeling that these mailboxes are not monitored.
Did anyone get any alternative method?
Related
Requesting guidance on how to get the OAuth Client Id whitelisted, so that Oauth works in Embedded browsers.
My Client id is : 665249451488-84nosliqrc80hpe0ot1vperj1eb8gbfk.apps.googleusercontent.com
Any email address / contact details for whitelisting will be helpful.
Similar question : Ios captive portal Google oauth disallowed agent - angular app
'disallowed_useragent' error on captive portal
Thanks in advance
Google OAuth does not work on embedded browsers because this is known to be insecure. See https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html and https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html. On iOS, you should use safariviewcontroller instead of relying on embedded web views.
As explained on the other question, if the issue your users are running into is a captive portal, this is the recommended way to continue to use Google Sign In: https://support.google.com/accounts/answer/9690282?hl=en.
Today I received an email with the above as subject and this in the body :
Dear Android developer,
To keep your access to Google APIs, review the OAuth client used by your Android application by September 30, 2019.
Google requires developers to register all Android apps that request Google Account data and interact with Google APIs. The following Android package name you maintain may require the registration of an OAuth client:
com.myappname (not my real app name)
To register an OAuth client, make sure to either:
Have an existing project on Google Cloud Platform for the app you publish.
Create a new project and configure it correctly.
For the app, make sure there’s an Android OAuth client for the package name and SHA-1 signing-certificate fingerprint. If your app uses certain sensitive or restricted scopes, you’ll also need to submit your app for verification.
Apps without a properly registered OAuth client may not get Google Account or API data after September 30, 2019.
Thanks,
Google API team
I have a GCP project that has 2 OAuth 2.0 client IDs with the package name for this Android app (one Debug, one Release) and SHA1 fingerprint. Google login has been working for years with no issue. App is also verified (though we don't use any sensitive scopes). Anybody received a similar email or know what possibly might be missing?
This is neither a misfire or a threat. It's more of a reminder than anything else. All people who interact with Google User data get this email, and the point of this is to simply tell people "Hey, if you need to, register an OAuth client, do it by September 30th.". This is explicitly clear on the wording of the email. You can see here:
The following Android package name you maintain may require the registration of an OAuth client
The keyword being "may". Since, from what you've posted, you already registered your client, you should be good to go. Everything beyond this:
com.myappname (not my real app name)
Is nothing more than instructions on how to register your client. Everything above it is warning, that if you haven't, register your client. It's saying that it's possible that you haven't registered your client, so make sure you have.
Long story short, if you registered your client, you're good to go.
Google Drive API question,
I am writing an application that can view a users' Google Drive files and folders from their google account (can be individual or part of an enterprise).
So on my Google Drive enterprise, I have created an API application. So I have an API key and Secret key stored in my application.
Now I want to use OAuth to authenticate the user so that they can approve my application to read their files. The users will not be part of my enterprise. They can be individual Google accounts, or they can be a single user from an some other enterprise account.
Is this possible? Or are there technical/security reasons this is not allowed?
I just got off the phone with wonderful Google api support agent, and I have my answer:
Yes this is possible to do. however due to the recent phishing attack, Google has put in place new security features that affect the following APIs:
Google drive
Gmail
Contacts
Directory Admin SDK
Here are the new rules:
There is a new security form we will need to fill out and be approved before we will be able to be approved as a trusted app that is able to access these api's using OAuth2 authentication.
Google has provided a feature that many enterprises use that allows an enterprise to completely disable the ability to access these api's using oauth2. So even though we have been approved from step1, we may still get an error for some enterprises who have directly blocked this; however, they can white list us in order to allow it from our enterprise if admin's prefer, while still blocking general use for others.
See links:
https://support.google.com/a/answer/7281227
https://developers.google.com/drive/v3/web/about-auth
https://developers.google.com/identity/protocols/OAuth2
https://www.reddit.com/r/google/comments/692cr4/new_google_docs_phishing_scam_almost_undetectable/
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.
I'm currently planning a new web project. Clients are going to connect using a regular web browser and, in case of regular java-enabled cell phones, j2me client. I would really like to make use of the OpenID authentication. In case of regular web browser things are pretty straightforward. However, I am really not sure about installed applications (such as j2me client installed on a mobile device) - regular OpenID authentication is performed by entering username/password on a webpage of particular OpenID provider - which is quite a limitation :)
Has anyone coped with such a situation? Is it possible to create authentication mechanism to the site that uses OpenID from a mobile j2me client?
Currently, I think of solution that users who would like to connect from their mobiles download necessary j2me application from the server web site after they have authenticated themselves (regular browser authentication). The mobile client app could be assembled dynamically on the server with the SSL certificate embedded that is associated with particular logged in OpenID user. After that, j2me client could authenticate to the server without entering any username/password. The data that is going to be stored on the server is not THAT sensitive - considering cases of mobile phone thefts etc.
Can anybody come up with a better solution?
The best solution IMO for what you're doing is to use OAuth combined with OpenID. You're use of OpenID at the RP is fine. But for installed applications that need access to that web site, they should use OAuth to get authorized. The flow would work like this:
User installs app on their device
During install or on first launch, the app has an "Authorize me" button.
The user presses the button and a web browser pops up the web site that the client app needs to access data from.
User logs into that site using their OpenID
Site now asks "do you want to authorize client app X?"
User says yes and closes the browser.
The client app reappears and says "thanks." and now has the OAuth token necessary to access the user's data without the user ever logging in again.