单页应用程序中的安全身份验证/授权

Posted 2023-02-19

【中文标题】单页应用程序中的安全身份验证/授权

【英文标题】：Secure authentication/authorisation in a Single-Page Application

【发布时间】：2016-12-27 17:55:09

【问题描述】：

我正在构建以下内容：

javascript 单页应用程序； Node.js 后端公开 RESTful API，用于存储用户数据；

用户凭据（电子邮件/密码）可以通过单页应用程序创建并存储在后端。无需与外部提供者交互，例如Facebook Login,，但将来可能需要。

一旦用户使用其凭据进行身份验证，单页应用程序应通过其 RESTful API 与后端交互。

---

我正在努力了解如何基于凭据以既安全又与单页应用程序的约束兼容的方式设置用户身份验证和授权。

我找到了有关 OAuth 2.0 和 JSON Web 令牌 的信息。我无法想象我应该如何使用这些技术来实现我的最终目标，无论它们是应该协同工作还是独立工作，我正在努力意识到每种技术所带来的陷阱。

---

您能否提供为具有自定义后端的单页应用程序构建成功的身份验证/授权机制所需的步骤和组件的演练，如果可能的话，还包括以下主题：

与 JWT 或其他方法相比，使用 OAuth 2.0 的优点/缺点； 使用 cookie 而不是以不同的方式存储令牌（例如 LocalStorage）和安全隐患；

【参考方案1】：

您可以使用不带 Oauth2 的 JWT 和不带 JWT 的 Oauth2，或者将它们一起使用。

请记住，OAuth2 管理授权而不是身份验证。 OAuth2 不介意如何验证您的用户。要处理身份验证，你可以看一下OpenId Connect，它是 Oauth2 之上的一层。 OpenId Connect 将向您的应用程序发送一个签名的 id_token，其中包含有关用户身份的信息。

使用 OpenId Connect 对用户进行身份验证后，您可以联系您的 OAuth 服务器以获取 access_token（JWT 与否）。此令牌将用于联系您的 API。对于 SPA 应用程序，建议使用 Implicit Grant flow。

对于 JWT，它用于 id_token（来自 OpenId Connect），也可用于 access_token (OAuth2)。对于 access_token，您的令牌可以是引用（推荐用于 SPA）或值。

通过引用，您的令牌对客户来说是不透明的（例如 guid）。通过值，您的令牌是可解析的，并且客户端可以读取包含的数据。

对于要使用的组件，我个人使用 RedHat 的 Keycloak。

希望对你有帮助。