适用于公共第一方客户的适当OAuth2流程

Question

我是堆栈溢出的常客,但这是我的第一个问题.

我正在使用OAuth2规范开发授权服务器.我只是在使用密码流时如何确保第一方客户端的真实性.我读了很多论坛,这就是我得到的:

1. Javascript单页客户端

   这篇由Alex Bilbie撰写的博客文章指出,要避免client_secret问题,我们应该:

   这很简单; 通过瘦服务器端组件代理所有API调用.这个组件(我们从这里开始称之为代理)将验证来自用户会话的ajax请求.访问和刷新令牌可以以加密形式存储在cookie中,只有代理才能解密.应用程序客户端凭据也将硬编码到代理中,因此它们也不可公开访问.

   但现在这个代理可以被冒充我的角度应用的人访问.然后我从安迪菲尔德那里看到了这篇博文:单页应用的OAuth2资源所有者密码流的安全性如何.他基本上说要依靠CORS来避免冒充JS客户端.

   使用这两种方法保护我的JS应用程序是个好主意吗？

2. 原生应用(桌面和移动)

   对于移动应用程序,我只找到了授权代码和隐式流程的案例.这不是我想要的,因为重定向会损害用户体验.所以我对此的看法是:

   我将使用ROP流程,然后使用client_id为此特定安装生成的客户端注册客户端, 并将其附加到用户帐户,接收access_token和 client_secret响应.此客户端发出的任何其他令牌请求必须携带此凭据(因为client_id特定于安装,我将能够检查此客户端是否已经过身份验证).这样,如果有人使用任何凭证来模拟客户端,甚至注册虚假客户端,我可以使用mesures来撤销用户和客户端访问.

我知道这可能是过度思考,我也知道其中一些事情并不能避免任何事情.我觉得我的工作就是尽我所能来保护我的API.

我非常感谢您对此事的看法!我是否真的过度思考？我应该只使用"公共客户"的概念继续吗？

谢谢大家,快乐编码!

Answer 1

首先，这个问题不是一个普遍优先考虑的问题，因为大多数应用程序都是先用网站开发的，然后才是 API。这可能是原因，因为没有人知道如何与 oauth2 打交道，因为每个人都开发了其他方法来做到这一点，而 oauth2 仅用于授予用户访问第三方应用程序的权限。

即使您只为您的第一个客户端应用程序开发了 oauth2 授权服务器（考虑单个身份验证机制而不是开发多个），您也应该尝试开发授权代码或隐式授权类型。您将意识到您需要一种方法来检查实际登录的用户。

常用的两种方法是：

• 用户会话（基于 Cookie）
• 来自 localStorage 的用户访问（基于 javascript）

无论哪种方式，您都需要检查应用程序的安全性，用户会话易受 CSRF 攻击，localStorage 易受 XSS 攻击。有很多关于如何保护您的网站的文章，因此我不会在这里提出任何建议，您只需要知道它们存在。

既然您选择了身份验证方法，我们就可以开始考虑：

Javascript 单页应用程序

1. 代理
   在我看来，拥有一个过滤所有请求的代理就像有一扇门总是插入钥匙。连造门都没用。但是，对于基于会话的身份验证，这是唯一的方法。在您的 Rest API 上允许会话身份验证将导致 CSRF 安全问题，因此您需要有一个代理层来获取用户会话，从会话中检索访问令牌并向 Rest API 添加Authorization标头的请求。

2. CORS
   使用这种方法需要将用户访问令牌存储在localStorage 中，因为令牌是直接从Js 客户端检索的。
   使用 CORS，您可以确定其他网站无法从浏览器向您的 Rest API 发出请求。但是您的第一个客户需要是公开的（即：它没有client_secret）。

本机应用程序（桌面和移动）

在我的第一个应用程序中，我尝试使用您建议的相同机制来保护身份验证流程。但是，这种机制要求您以独特的方式识别每个用户客户端。出于隐私原因，这在 iOS 中是不可能的，并且有可能在未来的 Android 版本中被拒绝。因此，您应该依赖公共客户端并仅client_id在您的本机应用程序代码中添加 。

这意味着您的本机应用程序客户端/您的 js 客户端可以非个性化吗？
是的，并且无法使用 oAuth2 资源所有者密码凭据授予类型来防止这种情况。

这样做的主要原因是因为 oAuth2 不用于身份验证，仅用于第三方授权，并且该授权类型仅针对受信任的特定第三方应用程序添加，可以直接使用用户密码。你可以在这里和这里阅读更多关于这个论点的信息。

在末尾

您仍然需要一种方法来授权您的用户，我认为使用 oAuth2 可以达到的最佳效果就是Auth0所做的。本质上，这个 Saas 使用 oAuth2 服务器 + OpenID 连接管理您的用户，因此您始终像管理第三方应用程序一样管理您的用户，并且一切正常。

实际上，您可以在此页面上看到，对于移动应用程序，他们建议使用基于浏览器的登录表单，因为每个反编译您的应用程序的人都可以将原生表单非个性化，但是如果您将其包装到授权代码流中，它就可以正常工作。