什么是适用于移动应用程序的OAuth 2.0流程 [英] What's the right OAuth 2.0 flow for a mobile app

问题描述

我正在尝试使用OAuth 2.0在Web API中为移动应用程序实现委托授权.根据规范，隐式授予流不支持刷新令牌，这意味着在特定时间段内授予访问令牌后，令牌到期或被吊销后，用户必须再次向应用授予权限.

我认为对于规范中提到的在浏览器上运行的某些javascript代码来说，这是一个很好的方案.我试图尽量减少用户必须授予应用程序权限以获取令牌的时间，因此授权代码流似乎是一个不错的选择，因为它支持刷新令牌.

但是，此流程似乎严重依赖于Web浏览器来执行重定向.我想知道，如果使用嵌入式Web浏览器，那么对于移动应用程序来说，这种流程是否仍然是一个不错的选择.还是应该使用隐式流程?

解决方案

说明:移动应用=本地应用

正如其他评论和一些在线资源所述，隐式似乎很适合移动应用程序，但是最好的解决方案并不总是很明确(实际上，出于下面讨论的原因，不建议使用隐式).

Native App OAuth2最佳实践

无论选择哪种方法(都需要权衡考虑)，您都应注意此处针对使用OAuth2的本机应用程序概述的最佳做法: https://tools.ietf.org/html/rfc8252 #section-8.2

OAuth 2.0隐式授予授权流程(在OAuth 2.0 [RFC6749]的4.2节中定义)通常与在浏览器中执行授权请求并通过基于URI的应用间通信接收授权响应的做法配合使用. br> 但是，由于隐式流不能受到PKCE [RFC7636](第8.1节中的要求)的保护，因此不建议在本机应用程序中使用隐式流.

在没有用户交互的情况下，也无法刷新通过隐式流授予的访问令牌，从而使授权码授予流- 可以发出刷新令牌-需要刷新访问令牌的本机应用授权的更实用选项.

授权码

如果您确实使用了授权码，那么一种方法是通过您自己的Web服务器组件进行代理，该组件利用客户端机密来丰富令牌请求，以避免将其存储在设备上的分布式应用程序中.

以下摘录自: https://dev.fitbit.com/docs/oauth2/

对于以下应用程序，建议使用授权码授予流程 有一个网络服务.此流程需要服务器到服务器的通信 使用应用程序的客户机密.

注意:切勿将客户端秘密放在分布式代码(例如应用程序)中 通过应用商店或客户端JavaScript下载.

没有Web服务的应用程序应使用隐式 拨款流程.

结论

在对入围方法进行适当的风险评估并更好地理解其含义后，最终决定应考虑到您期望的用户体验以及风险偏好.

请阅读 https://auth0. com/blog/oauth-2-best-practices-for-native-apps/

另一个是 https://www.oauth.com/oauth2-服务器/oauth-native-apps/其中指出

当前行业最佳实践是使用授权流程 同时省略客户端机密，并使用外部用户代理 完成流程.外部用户代理通常是设备的 本机浏览器(具有与本机应用程序不同的安全域) 因此该应用无法访问Cookie存储或检查或修改 浏览器中的页面内容.

PKCE注意事项

您还应该考虑此处 https://www.oauth.com/oauth2-servers/pkce/

具体来说，如果您还要实施授权服务器，则 https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/指出您应该

• 允许客户端为其重定向URL注册自定义URL方案.
• 支持具有任意端口号的环回IP重定向URL，以支持桌面应用程序.
• 不要以为本地应用程序可以保守秘密.要求所有应用声明它们是公开的还是机密的，并且仅向机密应用发布客户端机密.
• 支持PKCE扩展，并要求公共客户端使用它.
• 尝试检测授权界面何时嵌入在本机应用的网络视图中，而不是在系统浏览器中启动，并拒绝这些请求.

网络视图注意事项

有很多使用Web Views的示例，例如嵌入式用户代理，但是应避免使用这种方法(特别是在应用不是第一方的情况下)，在某些情况下，可能会导致您被禁止使用API如以下摘录自此处演示

任何嵌入OAuth 2.0身份验证页面的尝试都会导致 您的应用程序被Fitbit API禁止.

出于安全考虑，OAuth 2.0授权页面必须为 在专用的浏览器视图中显示. Fitbit用户只能确认 如果他们有的话，他们正在使用真实的Fitbit.com网站进行身份验证 浏览器提供的工具，例如URL栏和Transport 层安全(TLS)证书信息.

对于本机应用程序，这意味着必须打开授权页面 在默认浏览器中.本机应用程序可以使用自定义URL方案 作为重定向URI，用于将用户从浏览器重定向回至 申请许可.

iOS应用程序可以使用SFSafariViewController类而不是 应用切换到Safari.使用WKWebView或UIWebView类是 禁止.

Android应用程序可能会使用Chrome自定义标签，而不是应用程序 切换到默认浏览器.禁止使用WebView.

为进一步澄清，这是来自上面提供的最佳做法链接的先前草案的本部分

嵌入式用户代理(通常通过网络视图实现)是 授权本机应用程序的另一种方法.他们是 根据定义，由第三方使用是不安全的.他们涉及到用户 使用其完整的登录凭据登录，只是为了获得它们 下调至功能较弱的OAuth凭据.

即使被受信任的第一方应用程序使用，嵌入式用户代理 通过获得更强大的功能来违反最小特权原则 凭证，而不是所需的凭证，可能会增加攻击范围.

在典型的基于Web视图的嵌入式用户代理实现中， 主机应用程序可以:将在表单中输入的每个击键记录到 捕获用户名和密码；自动提交表格并绕过 用户同意；复制会话Cookie并使用它们执行 经过身份验证的操作作为用户.

鼓励用户在嵌入式网络视图中输入凭据，而无需 浏览器具有通常的地址栏和其他标识功能 使用户无法知道他们是否正在登录 合法站点，即使它们存在，它也会训练他们确定 无需先验证站点即可输入凭据.

除安全问题外，网络视图不共享 与其他应用程序或系统浏览器的身份验证状态，要求 用户针对每个授权请求登录并导致 糟糕的用户体验.

由于上述原因，不建议使用嵌入式用户代理， 除非受信任的第一方应用程序充当外部用户- 其他应用程式的代理程式，或提供多个首次登入的单一登入功能， 派对应用.

授权服务器应考虑采取步骤来检测和阻止 通过不是自己的嵌入式用户代理登录，其中 可能.

这里也提出了一些有趣的观点: 解决方案

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).

Native App OAuth2 Best Practises

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://tools.ietf.org/html/rfc8252

Consider the following options

Implicit

Should I use implicit?

To quote from Section 8.2 https://tools.ietf.org/html/rfc8252#section-8.2

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.

Authorization Code

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.

Excerpt below from: 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.

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.

Conclusion

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.

A great read is here https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

Another one is https://www.oauth.com/oauth2-servers/oauth-native-apps/ which states

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 Consideration

You should also consider PKCE which is described here https://www.oauth.com/oauth2-servers/pkce/

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

• Allow clients to register custom URL schemes for their redirect URLs.
• Support loopback IP redirect URLs with arbitrary port numbers in order to support desktop apps.
• Don’t assume native apps can keep a secret. Require all apps to declare whether they are public or confidential, and only issue client secrets to confidential apps.
• Support the PKCE extension, and require that public clients use it.
• Attempt to detect when the authorization interface is embedded in a native app’s web view, instead of launched in a system browser, and reject those requests.

Web Views Consideration

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

Any attempt to embed the OAuth 2.0 authentication page will result in your application being banned from the Fitbit API.

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.

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 applications may use the SFSafariViewController class instead of app switching to Safari. Use of the WKWebView or UIWebView class is prohibited.

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

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.

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.

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屋！