I'm trying to migrate an Android application using OAuth 1.0a to OAuth 2.0. (using the Google API Client Library for Java/Android for my OAuth 2.0 needs).
What is the best/preferred solution for accessing Google APIs using OAuth 2.0 on an Android platform that takes into account the usability aspect as well. The user should be able to autorize access in an easy way, seamlessly integrating with my Android app.
The application is currently using the OAuth 1.0 web based flow, where my application pops a browser to let the user authorize access, and using a custom redirect URI, my application is capable of retrieving an access token. It works pretty well, but I didn't like the fact that I need to leave my app in order to pop a brower to display a webpage. I was thinking that OAuth 2.0 might work around this, and allow for a better user experience.
I started looking at the Adroid AccountManager-OAuth2 integration as outlined at Google IO, as it doesn't involve a webbrowser, and is more tightly coupled with Android, but it is simply not working the way it should. It's not documented, and unclear if it will remain a viable option for the future.
I've now started investigating the standard OAuth 2.0 web flow.
Here I seem to be having 2 options :
Configure the OAuth 2.0 client as an installed app, and use the urn:ietf:wg:oauth:2.0:oob redirect URI.
Not very clean solution, as I'm not going to have my users copy-paste some code into my app. This is not user-friendly at all.
The Using OAuth 2.0 to Access Google APIs docs mention that there is some way of polling the title of the page to parse out the URL, but I also see a lot of usability issues with that, and don't really feel like writing this kind of plumbing code. If a client library exists that would do that for me, I'd be happy to investigate this further, but for now, I've dropped this option.
Configure the OAuth 2.0 client as a webapp, and use a redirect URI.
Here I noticed non-standard schemes are prohibited in OAuth 2.0. Before, it was possible to use something like xoauth://callback, but that's not allowed anymore.
When configuring a redirect URI like http://mysite.com/oauth2/callback, I'm unable to have Android open up my activity when the Google OAuth 2.0 page redirects, despite having setup a proper intent filter for it. The http://mysite.com/oauth2/callback is simply displayed in my browser.
The following does work
Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse("http://mysite.com/oauth2/callback"));
startActivity(i);
But when the Google OAuth 2 page redirects to that same URL, it is simply displayed in the browser.
Even if this would work, the user would still be presented with a chooser popup (open in browser or open using my Android Activity). From a usability perspective, this is also not acceptable.
I'm looking for a better solution than the ones outlined here.
Regards,
Davy
I ended up using a WebView component to load up the Google Authorization URL.
Using a WebviewClient, I was able to intercept the pages being loaded into the Webview, and as such, when the user accepts or denies the authorization request, I was able to continue the flow.
If the user accepts, the URL that Google redirects to contains a "code" request param, and the application is able to exchange it for an OAuth 2.0 token.
If the user does not accept, the URL that Google redirects to contains a "error" request param, and the application can handle the non-happy scenario.
I've written down everything in a blog post : Oauth 2.0 flow in Android
The post also contains a sample Android app using the OAuth 2.0 flow with the Latitude API. Sample code is available in GitGub.
Play Services were introduced at Google I/O 2013 and are now the official way to use OAuth2 in Android. They do not require a WebView.
Related
Setup:
Website with Google login button
Backend: nodejs + express
Frontend: Google Sign-in for Web (I know it is deprecated and I need to upgrade) https://developers.google.com/identity/sign-in/web/build-button
There is NO additional native Android or iOS app available
Situation:
I have received an email from Google stating that my web application client ID is receiving OAuth requests within an embedded webview, and I need to make some changes to these webviews to avoid man-in-the-middle attacks. This is a similar email: https://groups.google.com/g/omegaup-soporte/c/xrspGg8T94o
The subject of this email is: "[Action Advised] Take action to continue using Google's OAuth authorization endpoint" and the first statement is "We detected requests to our OAuth 2.0 authorization endpoint from one or more of your OAuth client IDs within an embedded webview context in the past 30 days.".
Question:
As stated above, my application is a web app, how is it possible that OAuth requests from an embedded webview are received?
As you see, Google disagrees with using webview.
Maybe, you can build your own sign in button with google icon and then add onclick event with window popup to solve this problem.
If you have any question, feel free to ask me.
I am developing an Android app with a REST API. The REST API needs authentication for security. I would like to use Google's OAuth2 provider since I the client will be on Android. I don't want to store passwords myself.
I'm trying to understand how the flow should work at a conceptual level. Authenticate to OAuth2 services describes how to get an OAuth token in the Android app. But then what? Do I need a route that accepts this token?
I am implementing the API with Django and Django Rest Framework. I found python-social-auth to implement OAuth flows for the API. It works great when I test manually in a browser going to http://localhost:8000/social/login/google-oauth2/. When I request that URL with a HTTP client, it returns HTML for a Google login page. In the Android app, should I load that in a WebView? And then what? That doesn't seem quite right to me since I'd rather use the Android OAuth API that I linked earlier.
What am I missing here and how do I solve this?
Our Android app is a minimal wrapper around our mobile-friendly website. This is by design.
Google OAuth is one means by which users can authenticate. With the announcement that WebView's will be blocked from Google OAuth, we are now looking at how to move forward.
My current plan is:
Use a JavascriptInterface to invoke native code when someone clicks on the web app's Sign in With Google button
Use Google Sign In to authenticate the user on the mobile app side.
Somehow send this authentication to the web server. Should I just redirect the user to the existing oauth callback URL?
Step 3 is where I'm not sure what the best approach is. It's a Ruby on Rails application using Omniauth.
Are there any examples of integrating Google Sign In with an almost entirely WebView-based application? Is this approach the right way to go about it?
The solution described in Authenticate with a backend server sounds just like what you want to do in step 3, though without using the OAuth callback URL.
Unfortunately, I could not find any reference on how to use it with OmniAuth.
I am extremely new to the OAuth framework and am currently working on writing a client on the android platform.
When trying to register my application with the api provider, it asks for a redirect url. I searched around bit and found some literature that says that it is a security feature to avoid phishing attacks and stuff like that.
I am kind of confused with what I learnt. Practically speaking, as a client developer, how should I go about with the redirect url? Is there a guideline that I need to follow? Does it take arbitrary values?
Any help will be appreciated.
Thanks.
The goal of the redirect URL is to prevent a developer of a malicious website from tricking the OAuth server from generating a token intended for you and giving it to them. The potential vulnerability is:
Request to https://oauth.server.com/login?app_id=2&redirect_uri=https://malicious.com
Upon user logging in, OAuth server generates a token and redirects to https://malicious.com?token=xxx
If the above flow works, the malicious server gets a valid token it can then use to interact with your application.
Instead when you register your application they ask for the return URL straight away. This enables them to always redirect to the same URL for your application and therefore always pass the valid token to a known application.
This part of the OAuth flow is covered in the OAuth 2 spec section 3.1.2 Redirection Endpoint. There are quite a few rules for it so I won't quote it here.
If you are consuming this token via an API rather than through the OAuth flow then you probably don't need the redirect URL.
Is there a way to implement oAuth flow without actually launching browser or even a webview on android?
What I want to show is a native Popup which asks user credentials and then supply it to oAuth provider.
Strictly speaking no, the main idea with OAuth is that you should never handle the user's credentials in any way.
But it depends on the provider. Twitter for example uses their own invention xAuth where you send the username and password in exchange for an access token. Twitter only allows this for applications that can motivate that need very well though.
So check with the API provider if it is possible in some way.
Recently i did some research regarding implement oAuth without using browser or webview. Nowadays some platform already has native way by using their SDK like google: https://developers.google.com/identity/sign-in/android/, linkedin : https://developer.linkedin.com/docs/android-sdk-auth#. You can search for other platform too.
Another chance i see is by using google "Firebase" : https://firebase.google.com/docs/auth/. Even though i am not yet really try to implement it, as my understanding we can create our own custom input on HTML and pass it to their Javascript oAuth SDK to do credential login transaction. Just my guess we can do it with android native interface too.
Any correction are very welcome. Thanks.