移动应用程序的正确 OAuth 2.0 流程是什么 [英] What's the right OAuth 2.0 flow for a mobile app
问题描述
我正在尝试在使用 OAuth 2.0 的移动应用程序的 Web API 中实现委托授权.根据规范，隐式授予流程不支持刷新令牌，这意味着一旦访问令牌被授予特定时间段，一旦令牌过期或被撤销，用户必须再次向应用授予权限.
I am trying to implement delegated authorization in a Web API for mobile apps using OAuth 2.0. According to specification, the implicit grant flow does not support refresh tokens, which means once an access token is granted for an specific period of time, the user must grant permissions to the app again once the token expires or it is revoked.
我想对于在浏览器上运行的一些 javascript 代码来说，这是一个很好的场景，正如规范中提到的那样.我试图最大限度地减少用户必须授予应用程序权限以获取令牌的时间，因此授权代码流看起来是一个不错的选择，因为它支持刷新令牌.
I guess this is a good scenario for some javascript code running on a browser as it is mentioned in the specification. I am trying to minimize the times the user must grant permissions to the app to obtain a token, so it looks like the Authorization Code flow is a good option as it supports refresh tokens.
但是，此流程似乎严重依赖网络浏览器来执行重定向.我想知道如果使用嵌入式 Web 浏览器，此流程对于移动应用程序是否仍然是一个不错的选择.还是我应该使用隐式流程?
However, this flow seems to rely heavily on a web browser for performing the redirections. I am wondering if this flow is still a good option for a mobile app if a embedded web browser is used. Or should I go with the implicit flow ?
推荐答案
澄清:移动应用 = 原生应用
Clarification: Mobile App = Native App
正如其他评论和一些在线来源所述，隐式似乎很适合移动应用，但最佳解决方案并不总是明确的(事实上，由于下面讨论的原因，不建议使用隐式).
As stated in other comments and a few sources online, implicit seems like a natural fit for mobile apps, however the best solution is not always clear cut (and in fact implicit is not recommended for reasons discussed below).
原生应用 OAuth2 最佳实践
无论您选择哪种方法(有一些权衡需要考虑)，您都应该注意此处针对使用 OAuth2 的本机应用程序概述的最佳做法:https://www.rfc-editor.org/rfc/rfc8252
Whatever approach you choose (there are a few trade offs to consider), you should pay attention to the best practices as outlined here for Native Apps using OAuth2: https://www.rfc-editor.org/rfc/rfc8252
考虑以下选项
隐式
我应该使用隐式吗?
引用第 8.2 节 https://www.rfc-editor.org/rfc/rfc8252#section-8.2
OAuth 2.0 隐式授予授权流程(在 OAuth 2.0 [RFC6749] 的第 4.2 节中定义)通常适用于在浏览器中执行授权请求并通过基于 URI 的应用间通信接收授权响应的做法.
但是，由于 PKCE [RFC7636] 无法保护隐式流(第 8.1 节要求)，不推荐将隐式流与本机应用程序一起使用.
The OAuth 2.0 implicit grant authorization flow (defined in Section 4.2 of OAuth 2.0 [RFC6749]) generally works with the practice of performing the authorization request in the browser and receiving the authorization response via URI-based inter-app communication.
However, as the implicit flow cannot be protected by PKCE [RFC7636] (which is required in Section 8.1), the use of the Implicit Flow with native apps is NOT RECOMMENDED.
通过隐式流程授予的访问令牌也无法在没有用户交互的情况下刷新，从而使授权代码授予流程-它可以发出刷新令牌——对于需要刷新访问令牌的原生应用授权来说，这是更实用的选项.
Access tokens granted via the implicit flow also cannot be refreshed without user interaction, making the authorization code grant flow -- which can issue refresh tokens -- the more practical option for native app authorizations that require refreshing of access tokens.
授权码
如果您确实使用授权码，那么一种方法是通过您自己的 Web 服务器组件进行代理，该组件使用客户端机密丰富令牌请求，以避免将其存储在设备上的分布式应用程序中.
If you do go with Authorization Code, then one approach would be to proxy through your own web server component which enriches the token requests with the client secret to avoid storing it on the distributed app on devices.
以下摘录自:https://dev.fitbit.com/docs/oauth2/
建议将授权代码授予流程用于以下应用程序有一个网络服务.此流程需要服务器到服务器的通信使用应用程序的客户端机密.
The Authorization Code Grant flow is recommended for applications that have a web service. This flow requires server-to-server communication using an application's client secret.
注意:切勿将您的客户端密码放在分布式代码中，例如应用程序通过应用商店或客户端 JavaScript 下载.
Note: Never put your client secret in distributed code, such as apps downloaded through an app store or client-side JavaScript.
没有网络服务的应用程序应该使用隐式拨款流程.
Applications that do not have a web service should use the Implicit Grant flow.
结论
在对入围方法进行适当的风险评估并更好地了解其影响后，最终决定应考虑您所需的用户体验以及您的风险偏好.
The final decision should factor in your desired user experience but also your appetite for risk after doing a proper risk assessment of your shortlisted approaches and better understanding the implications.
这里有一个很好的读物https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
另一个是https://www.oauth.com/oauth2-servers/oauth-native-apps/ 说明
当前行业最佳实践是使用授权流程同时省略客户端机密，并使用外部用户代理完成流程.外部用户代理通常是设备的本机浏览器，(与本机应用程序具有单独的安全域，)使应用程序无法访问 cookie 存储或检查或修改浏览器内的页面内容.
The current industry best practice is to use the Authorization Flow while omitting the client secret, and to use an external user agent to complete the flow. An external user agent is typically the device’s native browser, (with a separate security domain from the native app,) so that the app cannot access the cookie storage or inspect or modify the page content inside the browser.
PKCE 考虑
您还应该考虑此处描述的 PKCE https://www.oauth.com/oauth2-servers/pkce/
You should also consider PKCE which is described here https://www.oauth.com/oauth2-servers/pkce/
具体来说，如果您还实施授权服务器，则 https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ 声明你应该
Specifically, if you are also implementing the Authorization Server then https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ states that you should
- 允许客户端为其重定向 URL 注册自定义 URL 方案.
- 支持具有任意端口号的环回 IP 重定向 URL，以支持桌面应用程序.
- 不要假设原生应用可以保守秘密.要求所有应用声明它们是公开的还是机密的，并且只向机密应用发布客户端机密.
- 支持 PKCE 扩展，并要求公共客户使用它.
- 尝试检测授权界面何时嵌入本机应用的网络视图中，而不是在系统浏览器中启动，并拒绝这些请求.
网络浏览量考虑
有很多使用 Web Views 的例子，即嵌入式用户代理，但这种方法应该避免(特别是当应用程序不是第一方时)，并且在某些情况下可能会导致您被禁止使用 API如以下摘录自此处演示
There are many examples in the wild using Web Views i.e. an embedded user-agent but this approach should be avoided (especially when the app is not first-party) and in some cases may result in you being banned from using an API as the excerpt below from here demonstrates
任何嵌入 OAuth 2.0 身份验证页面的尝试都将导致您的应用程序被 Fitbit API 禁止.
Any attempt to embed the OAuth 2.0 authentication page will result in your application being banned from the Fitbit API.
出于安全考虑，OAuth 2.0 授权页面必须是在专用浏览器视图中显示.Fitbit 用户只能确认他们正在通过真正的 Fitbit.com 网站进行身份验证，如果他们有浏览器提供的工具，如网址栏和传输层安全 (TLS) 证书信息.
For security consideration, the OAuth 2.0 authorization page must be presented in a dedicated browser view. Fitbit users can only confirm they are authenticating with the genuine Fitbit.com site if they have the tools provided by the browser, such as the URL bar and Transport Layer Security (TLS) certificate information.
对于原生应用，这意味着授权页面必须打开在默认浏览器中.本机应用程序可以使用自定义 URL 方案作为重定向 URI 将用户从浏览器重定向回申请许可.
For native applications, this means the authorization page must open in the default browser. Native applications can use custom URL schemes as redirect URIs to redirect the user back from the browser to the application requesting permission.
iOS 应用程序可以使用 SFSafariViewController 类代替应用程序切换到 Safari.WKWebView 或 UIWebView 类的使用是禁止.
iOS applications may use the SFSafariViewController class instead of app switching to Safari. Use of the WKWebView or UIWebView class is prohibited.
Android 应用程序可能会使用 Chrome 自定义标签而不是应用程序切换到默认浏览器.禁止使用 WebView.
Android applications may use Chrome Custom Tabs instead of app switching to the default browser. Use of WebView is prohibited.
为了进一步澄清，这里引用了 本节 上面提供的最佳实践链接的先前草稿
To further clarify, here is a quote from this section of a previous draft of the best practise link provided above
嵌入式用户代理，通常用网络视图实现，是一种授权本机应用程序的替代方法.然而他们根据定义，第三方使用不安全.它们涉及用户使用他们的完整登录凭据登录，只是为了让它们缩小到功能较弱的 OAuth 凭据.
Embedded user-agents, commonly implemented with web-views, are an alternative method for authorizing native apps. They are however unsafe for use by third-parties by definition. They involve the user signing in with their full login credentials, only to have them downscoped to less powerful OAuth credentials.
即使由受信任的第一方应用程序使用，嵌入式用户代理通过获得更强大的力量来违反最小特权原则凭据超出他们的需要，可能会增加攻击面.
Even when used by trusted first-party apps, embedded user-agents violate the principle of least privilege by obtaining more powerful credentials than they need, potentially increasing the attack surface.
在典型的基于 Web 视图的嵌入式用户代理实现中，主机应用程序可以: 记录在表单中输入的每个按键捕获用户名和密码；自动提交表单并绕过用户同意；复制会话 cookie 并使用它们来执行作为用户进行身份验证的操作.
In typical web-view based implementations of embedded user-agents, the host application can: log every keystroke entered in the form to capture usernames and passwords; automatically submit forms and bypass user-consent; copy session cookies and use them to perform authenticated actions as the user.
鼓励用户在嵌入式 Web 视图中输入凭据，而无需浏览器通常具有的地址栏和其他身份特征使用户无法知道他们是否正在登录合法的网站，即使他们是，它也训练他们没关系无需先验证网站即可输入凭据.
Encouraging users to enter credentials in an embedded web-view without the usual address bar and other identity features that browsers have makes it impossible for the user to know if they are signing in to the legitimate site, and even when they are, it trains them that it's OK to enter credentials without validating the site first.
除了安全问题外，网络视图不共享与其他应用程序或系统浏览器的身份验证状态，需要用户登录每个授权请求并导致糟糕的用户体验.
Aside from the security concerns, web-views do not share the authentication state with other apps or the system browser, requiring the user to login for every authorization request and leading to a poor user experience.
由于上述原因，不推荐使用嵌入式用户代理，除非受信任的第一方应用程序充当外部用户 -其他应用程序的代理，或为多个首次登录提供单点登录派对应用.
Due to the above, use of embedded user-agents is NOT RECOMMENDED, except where a trusted first-party app acts as the external user- agent for other apps, or provides single sign-on for multiple first- party apps.
授权服务器应该考虑采取措施来检测和阻止通过不属于他们自己的嵌入式用户代理登录，其中可能.
Authorization servers SHOULD consider taking steps to detect and block logins via embedded user-agents that are not their own, where possible.
Some interesting points are also raised here: https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a
这篇关于移动应用程序的正确 OAuth 2.0 流程是什么的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
