选择 OIDC 授权模式

你需要根据你的场景和你开发的应用类型选择一种合适的认证授权模式。本文将协助你选择合适的 OIDC 授权模式。

推荐的授权模式

不同类型的应用,需要选择不同的授权模式。下面的表格中是我们推荐的模式:

应用类型 授权模式
有后端场景 授权码模式
SPA,无后端 隐式模式
服务器之间 Client Credentials

你的应用是否需要 Id Token?

授权模式 Access Token Id Token
授权码模式 :white_check_mark: :white_check_mark:
隐式模式 :white_check_mark: :white_check_mark:
密码模式 :white_check_mark: :white_check_mark:
Client Credentials 模式 :white_check_mark: :x:

你的应用是什么类型?

如何选择 OIDC 授权模式取决于你在开发哪种类型的应用。参考以下流程图来选择你需要的授权模式:

你的应用代码是否能被公开访问

如果你的终端用户能够看到并修改你的应用代码,那么这个应用就是公开访问的。包括 SPA(单页应用)和移动端应用。这种场景下,应用无法安全地存储密钥。

你的应用是 SPA 还是原生应用?

如果你的应用是一个单页应用,运行在新版本的浏览器中,并且浏览器支持 Web Crypto,你应该使用 PKCE + 授权码模式。如果你的应用运行在老旧版本的浏览器中,浏览器不支持 Web Crypto,你应该使用隐式模式。隐式模式仅适用于应用无法安全存储密钥的场景,如果其他模式不可用时你才应该考虑用隐式模式。

如果你的应用是原生应用,你应该使用 PKCE + 授权码模式。

有没有终端用户在使用你的应用?

如果你的应用运行在服务器端,没有直接给终端用户使用,只是在进行服务器之间的交互,你应该使用 Client Credentials 模式。

应用和资源是否都被同一方持有?

如果你的应用以及应用需要访问的资源都是由你掌握,而且你的应用可以安全地存储用户账密,代码逻辑足够安全。当其他授权模式都不合适时,你可以选择密码模式。

授权码模式

授权码模式适合应用具备后端服务器的场景。授权码模式要求应用必须能够安全存储密钥,用于后续使用授权码换 Access Token。授权码模式需要通过浏览器与终端用户交互完成认证授权,然后通过浏览器重定向将授权码发送到后端服务,之后进行授权码换 Token 以及 Token 换用户信息。

了解更多信息,请参考使用授权码模式

隐式模式

隐式模式适合不能安全存储密钥的场景(例如前端浏览器)。在隐式模式中,应用不需要使用 code 换 token,无需请求 /token 端点,AccessToken 和 IdToken 会直接从认证端点返回。

因为隐式模式用于不能安全存储密钥的场景,所以隐式模式不支持获取 Refresh Token。

了解更多信息,请参考使用隐式模式

密码模式

密码模式适用于你既掌握应用程序又掌握应用所需资源的场景。密码模式要求应用能够安全存储密钥,并且能够被信任地存储资源所有者的账密。一般常见于自家应用使用自家的资源。密码模式不需要重定向跳转,只需要携带用户账密访问 Token 端点。

了解更多信息,请参考使用密码模式

Client Credentials 模式

Client Credentials 模式用于进行服务器对服务器间的授权(M2M 授权),期间没有用户的参与。你需要创建编程访问账号,并将 AK、SK 密钥对交给你的资源调用方。

Client Credentials 模式不支持 Refresh Token。

了解更多信息,请参考使用 Client Credentials 模式

SPA,无后端,不是特别理解,SPA应用还会没有应用后端吗。我们平常都是有应用后端的吧?
不然页面的数据从哪里加载的呢,SPA不可能全部是静态页面。

那SPA,有应用后端,应该选择哪种模式呢?

这里说的「SPA,无后端」指的是你的后端服务不进行「code 换 token」操作,不是说没有后端为业务功能做支撑。SPA 场景下推荐使用隐式模式,当然开发 SPA 应用,同时在后端去处理「code 换 token」逻辑也是可以的。

隐式模式,OAuth 2.1已经废弃了,说这种方式不安全,为什么还在用呢?不是特别理解。

隐式模式出现的场景是因为解决SPA页面的用 授权码模式 交互不友好问题吗? 牺牲安全性?

虽然在大多数场景下已经不再推荐使用implicit flow,但是在部分条件限制比较严格的情况下仍就可以选用:


详情可以参考:选择 OIDC 授权模式 | Authing 文档