隐藏授权模式

看起来您可能指的是“隐式授权（Implicit Grant）”，这是 OAuth 2.0 定义的一种授权类型，专门用于无法妥善保管客户端密钥的公共客户端，如 JavaScript 单页面应用(SPA)。与授权码模式不同，隐式授权不涉及使用客户端密钥来交换访问令牌的过程，而是直接向客户端提供访问令牌。

隐式授权的工作流程

1. 发起授权请求：

   • 客户端将用户代理重定向到授权服务器的授权端点。这个请求包含了response_type=token参数（表示期望直接返回访问令牌）、客户端 ID、重定向 URI、请求的作用域（scope）、以及一个可选的状态参数（用于防止 CSRF 攻击）。

   https://authorization-server.com/auth?response_type=token&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=STATE

2. 用户登录并同意授权：

   • 用户在授权服务器上登录，并被提示是否同意给予客户端请求的权限。如果用户同意，授权服务器会处理请求。

3. 直接提供访问令牌：

   • 授权服务器通过将用户代理重定向回客户端指定的重定向 URI，并在重定向的 URL 片段中包含访问令牌、令牌类型、有效期等信息，直接提供访问令牌给客户端。

   REDIRECT_URI#access_token=ACCESS_TOKEN&token_type=bearer&expires_in=3600&state=STATE

4. 客户端提取访问令牌：

   • 客户端从 URL 片段中提取访问令牌，并可以立即使用它来访问受保护资源。由于整个过程发生在用户代理中，因此对于公共客户端来说，这种方式更加简便但也带来了额外的安全考量。

注意事项

• 安全性考虑：因为访问令牌是通过前端传递的，所以这种方式存在一定的安全风险。建议仅在完全信任的环境中使用，并采取额外措施，比如使用较短的令牌有效期、HTTPS 传输、以及适当的 CORS 配置。
• 不适合敏感操作：鉴于其相对较低的安全性，隐式授权不适合用于执行高敏感度的操作或处理非常敏感的数据。
• 状态参数：为了增强安全性，防止跨站请求伪造(CSRF)攻击，应该始终使用状态参数。

尽管隐式授权提供了较为简单的实现方式，但随着技术的发展，特别是对于 SPA 应用，现在更推荐使用授权码模式加上 PKCE（Proof Key for Code Exchange）扩展来代替隐式授权，以提高安全性。这种方法可以在不存储客户端密钥的情况下，仍然保持较高的安全性水平。