Auth0 的 OAuth 2.0 方案

2020-03-19 约 1110 字预计阅读 3 分钟

Auth0，一家“Identity-as-a-service”提供商。开发中的认证和授权是不可避免的，现如今互联网上的开放授权协议很多，如OpenID、OAuth2.0、SMAL等，当你想通过第三方登录时，你可能会遇到Weibo、QQ它们实现的协议都不同的情况，那你就必须针对它们使用的协议编写程序，这对开发人员前期编写、后期维护都很不方便。

Auth0 的角色就是一个代理人，帮你联通自己的系统和第三方系统，它把主流的授权协议都实现并封装好了，为多种主流语言提供了 SDK，当你的系统要支持第三方登录时，只需要调用 Auth0 的 API 即可。（但听说文档写的很差）

Auth0的产品策略：免费（登陆用户数小于1000）+ 定制。

允许用户在一个站点授予该站点有限的权限以获取用户的资源，而不用暴露另一个站点的凭证。

默认格式是 JWT ，在 OAuth 2.0 中权限被称作 scopes ，例如：read:contacts、create:contacts等

Resource Owner
Resource Server
Client
Authorization Server

OAuth 2.0 Authorization Framework specification 定义了获取 Access Token 的四种方式，它们被称作 grant types。具体选择哪一种取决于你的 APP 的类型。

分别是：

Authorization Code: used by Web Apps executing on a server. This is also used by mobile apps, using the Proof Key for Code Exchange (PKCE) technique.
Implicit: used by JavaScript-centric apps (Single-Page Applications) executing on the user’s browser.
Resource Owner Password Credentials: used by trusted apps.
Client Credentials: used for machine-to-machine communication.

Authorization Code Flow 单独使用时无法减轻安全威胁，因为：

对于 Native apps：

不能安全保存一个 Client Secret。反编译这个 app 就会揭示这个 Client Secret（与该 app 绑定，对所有用户和设备都是一致的）。
可能允许恶意 app 通过使用自定义的 URL 模式（如 MyApp://）来获取授权码。

对于 SPA：

不能安全保存一个 Client Secret，因为它的资源对浏览器来说都可用。

为了减轻这些安全问题，OAuth 2.0 提供了一个能利用 Proof Key for Code Exchange (PKCE) 的授权码工作流版本。原理是 app 创建一个 Code Verifier 并通过 HTTPS 传输 Code Challenge（Code Verifier 的 transform value）以获取授权码，这样以来，潜在的攻击者只能拦截到授权码，但是因为没有 Code Verifier 就不能用它获取 Token。

注意： OAuth 2.0 BCP 规定你 不应该 使用 Implicit Flow 从 Authorization Server 来请求 Access Tokens. 鉴于此，我们推荐你使用 Authorization Code Flow with PKCE 如果你的 single-page app (SPA) 需要 Access Tokens for Cross-Origin Resource Sharing (CORS) requests.

这种方式已经不是请求 Access Token 的最佳实践，如果只需要 ID Token 的话，那确实是合适的。

Implicit Flow 中，发布的 Token 是 short-lived ，并且 Refresh Token 不可用。