使用原生应用（Android）保护Oauth2中的身份验证代码 [英] Secure the Auth Code in Oauth2 with native apps (Android)

问题描述

该问题与 AppLinks资产链接几乎无关。 json似乎不用于验证

我正在Android上实现Oauth2应用。我想进行SSO（单点登录），并且对AppLink的安全性感到担忧。

I am implementing Oauth2 apps on Android. I would like to do SSO (single sign-on) and I have a concern about AppLink to secure the Autorization Code.

本机应用程序通过浏览器启动一个授权请求，然后接收包含授权代码的授权响应。根据 RFC6749＃section-4.1.2 ，代码已通过网址内：

The native app, through the browser, initiate an Authorization Request and then receive an Authorization Response containing the Authorization Code. According to RFC6749#section-4.1.2, the code is passed inside the URL:

HTTP / 1.1 302找到
位置：https://client.example.com/cb?code= SplxlOBeZQQYbYS6WxSbIA& state = xyz


授权代码是一条敏感信息，因为它允许客户端获取访问令牌和刷新令牌，然后访问受保护的资源。

Authorization Code is a sensitive piece of information because it allows a client to fetch an Access Token and Refresh Token and then access to a protected ressource.

要保护该代码，本机应用必须实现https方案重定向（ RFC8252＃section-7.2 & 第8.1 节）。在Android上，必须使用assetlinks.json文件

To protect that code, the native app must implement https scheme redirects (RFC8252#section-7.2 & section-8.1). On Android, that must be done using the assetlinks.json file

完成操作，但根据相关问题顶部链接，Android上的应用链接似乎并非100％安全，因为操作系统可能无法验证https方案。

But according to the related question linked at the top, app links on Android seems not to be 100% secure, because the OS may not verify the https scheme.

在那种情况下，我们应该如何实现Oauth2授权代码钩子？

In that context, how are we supposed to implement Oauth2 authorization code hook ?

根据@benjamin anwser，AppLink并非出于安全性考虑。但是，相关的威胁用例如下：已安装恶意应用程序，并使用 SSO Cookie获取了身份验证代码并将其交换为 AT + RT 。在我看来，此过程中没有什么可以阻止这种情况：如果applink出于安全性考虑，授权服务器如何才能知道此应用程序是恶意应用程序？

According to @benjamin anwser, AppLink is not for security. But, the related threat use-case is the following : a malicious app is installed and uses the "SSO Cookie" to get the Auth Code and exchange it for AT+RT. It seems to me that nothing in the process can prevent that case: if applink is not for security, how does the Authorization Server can be aware that this app is a malicious app ?

注意：通过SSO-Cookie，我的意思是使用 CustomTab 在Android上执行SSO。

Note: By SSO-Cookie, I mean the use of CustomTab to do SSO on Android.

推荐答案

不是AppLinks功能可以保证安全性。配置 /。well-known / assetlinks.json 文件时，它允许透明重定向到应用程序，而无需任何用户交互。这意味着通常不会出现的模式对话框会弹出，以选择用户要用于处理链接的应用程序。
如您所述，如果用户选择处理您与另一个应用程序的链接或尚未安装您的应用程序，则可以绕过此机制。用户需要进入电话设置才能达到以下目的：

It's not the AppLinks functionality that guarantees security. When you configure the /.well-known/assetlinks.json file it allows a transparent redirect to the application without any user interaction. This means that the modal dialog that usually appears to chose which application the user would like use to handle the link won't pop. As you stated, this mechanism can be bypassed if the user chooses to handle your link with another app or your app is not yet install. The user needs to go to the phone setting in order to achieve this :

设置> 应用>选择可以处理授权代码链接的应用程序> 默认打开> 在此应用程序中打开支持的链接>选择始终允许，这样第三方应用程序就可以捕获链接中包含的信息，在这种情况下，您可以使用授权码。

Settings > Apps > choose the application which can handle the Authorization Code link > Open by default > Open supported links in this app > choose Always allowThis way a third party application can catch the information contained in your link, in your case the Authorization Code.

话虽如此，它实际上是 代码证明密钥交换（PKCE） ，可确保授权码的安全性。您的服务器必须实施此功能，以减轻不必要的授权码重播。
关于 OAuth 授权步骤的小提示 PKCE ：

That been said, it's actually the Proof Key for Code Exchange (PKCE) that guarantees security of Authorization Code. Your server must implement this feature in order to mitigate unwanted Authorization Code replays. A little reminder on the OAuth authorization steps using PKCE :

1. 客户端（应用程序）呼叫 /授权具有哈希随机字符串的端点以及用于对其进行哈希的方法。客户端保留随机字符串（不进行哈希处理），因为它将在步骤3中使用。


2. 授权服务器检查用户是否输入了正确的登录名/密码。如果一切顺利，它将存储在请求中发送的散列随机字符串及其散列方法。然后，服务器使用包含授权代码的重定向将用户代理重定向到应用程序。


3. 为了检索它的访问令牌 ，客户端（应用程序）使用步骤1中生成的随机字符串调用 /令牌端点。


4. 服务器收到 / token 请求，提取随机字符串，并使用步骤2中存储的方法对其进行哈希处理。然后服务器必须检查此哈希字符串是否与存储在其中的字符串匹配。步骤2.如果字符串相同，则服务器以访问令牌和刷新令牌响应，否则返回错误。

1. The client (application) calls the /authorization endpoint with a hashed random string and the method which was used to hash it. The client keeps the random string (not hashed) because it will used in the step 3.
2. The authorization server checks if user entered a right login/password. If all it's good, it stores the hashed random string and it's hash method which were sent in the request. The server then redirect the user agent to the application with a redirection containing the Authorization Code.
3. In order to retrieve it's Access Token, the client (application) calls the /token endpoint with random string generated in step 1.
4. The server receives the /token request, extracts the random string and hashes it with the method stored in step 2. Then the server must checks that this hashed string matches the one stored in step 2. If the strings are the same, the server responds with an Access Token and a Refresh Token, otherwise with an error.

这是 PKCE 如何确保发出 / authorization 的客户端请求发出 /令牌请求的客户端。因此，即使第三方应用捕获了您的授权代码，它也无法使用它来检索访问令牌。

This is how the PKCE ensures that the client that made the /authorization request it's the same client that will make the /token request. So even if a third party app captures your Authorization Code it can't use it to retrieve Acess Tokens.

有关更多信息，请参见： PKCE（rfc 7636）和用于本机应用程序的OAuth 2.0（rfc 8252）

For more informations see : PKCE (rfc 7636) and OAuth 2.0 for Native Apps (rfc 8252)

这篇关于使用原生应用（Android）保护Oauth2中的身份验证代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！