在 Android 上使用 OAuth 2.0 使用 Google API 的最佳方式

发布于 2024-11-28 06:04:29 字数 1872 浏览 1 评论 0原文

我正在尝试将使用 OAuth 1.0a 的 Android 应用程序迁移到 OAuth 2.0。 (使用适用于 Java/Android 的 Google API 客户端库来满足我的 OAuth 2.0 需求)。

在 Android 平台上使用 OAuth 2.0 访问 Google API 的最佳/首选解决方案是什么,同时也考虑到可用性方面。用户应该能够以简单的方式自动授权访问,与我的 Android 应用程序无缝集成。

该应用程序当前使用基于 OAuth 1.0 Web 的流程,其中我的应用程序会弹出浏览器以让用户授权访问,并且使用自定义重定向 URI,我的应用程序能够检索访问令牌。它工作得很好,但我不喜欢这样的事实:我需要离开我的应用程序才能弹出浏览器来显示网页。我认为 OAuth 2.0 可能会解决这个问题,并提供更好的用户体验。

我开始查看 Google IO 中概述的 Adroid AccountManager-OAuth2 集成,因为它不涉及网络浏览器,并且与 Android 耦合更紧密,但它根本没有按照应有的方式工作。它没有记录在案,也不清楚它是否仍然是未来的可行选择。

我现在开始研究标准 OAuth 2.0 Web 流程。

这里我似乎有 2 个选项:

将 OAuth 2.0 客户端配置为已安装的应用程序,并使用 urn:ietf:wg:oauth:2.0:oob 重定向 URI。

不是很干净的解决方案,因为我我不会让我的用户将一些代码复制粘贴到我的应用程序中。这对用户来说根本不友好。

使用 OAuth 2.0 访问 Google API 文档提到有一些方法轮询页面标题来解析 URL,但我也看到了很多可用性问题,并且不太喜欢编写这种管道代码。如果存在可以为我做到这一点的客户端库,我很乐意进一步调查这一点,但现在,我已经放弃了这个选项。

将 OAuth 2.0 客户端配置为 Web 应用程序,并使用重定向 URI。

这里我注意到 OAuth 2.0 中禁止使用非标准方案。以前,可以使用 xoauth://callback 之类的东西,但现在不再允许了。 配置诸如 http://mysite.com/oauth2/callback 之类的重定向 URI 时,我无法当 Google OAuth 2.0 页面重定向时,Android 会打开我的 Activity,尽管已为其设置了适当的意图过滤器。 http://mysite.com/oauth2/callback 仅显示在我的浏览器中。

以下确实有效,

Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse("http://mysite.com/oauth2/callback"));
startActivity(i);

但是当 Google OAuth 2 页面重定向到同一 URL 时,它只是显示在浏览器中。

即使这可行,用户仍然会看到一个选择器弹出窗口(在浏览器中打开或使用我的 Android Activity 打开)。从可用性角度来看,这也是不可接受的。

我正在寻找比此处概述的更好的解决方案。

问候, 戴维

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

九局 2024-12-05 06:04:29

我最终使用 WebView 组件来加载 Google 授权 URL。
使用 WebviewClient,我能够拦截正在加载到 Webview 中的页面,因此,当用户接受或拒绝授权请求时,我能够继续流程。

如果用户接受,Google 重定向到的 URL 将包含“代码”请求参数,并且应用程序能够将其交换为 OAuth 2.0 令牌。
如果用户不接受,Google 重定向到的 URL 会包含“错误”请求参数,并且应用程序可以处理不愉快的情况。

我已经在博客文章中写下了所有内容:Android 中的 Oauth 2.0 流程

该帖子还包含一个使用 OAuth 2.0 流程和 Latitude API 的示例 Android 应用程序。 示例代码可在 GitGub 中找到

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.

双手揣兜 2024-12-05 06:04:29

Play 服务于 2013 年 Google I/O 大会上推出,现已成为使用 OAuth2 的官方方式在 Android 中。它们不需要 WebView。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文