是否应该使用 ID 令牌或访问令牌来授权 SPA 功能？

Question

上下文

我有一个与后端 REST API 通信的单页应用程序。此 REST API 专门用于为 SPA 服务。为了在主页之外导航或使用 SPA 的任何功能，用户必须先登录。我将 OIDC 与 Okta 一起使用来验证用户身份。用户可以具有管理员角色或用户角色。他们的角色将用于授权他们可以导航到哪些 SPA 页面，以及允许他们进行哪些 REST API 调用。

问题

1. 用户登录后，我的应用程序会收到来自 Okta 的 ID 令牌和访问令牌。我可以选择将用户的角色作为自定义声明包含在 ID 令牌或访问令牌中。哪个令牌应包含此信息？两者都有？

2. UI 需要根据用户角色做出一些授权决策。 例如，要显示或隐藏哪些 HTML 元素，以及哪些 SPA 路由是可导航的。应该通过检查 ID 令牌还是访问令牌来做出这些决定？其他？

3. 通过 SPA 调用我的后端 API 时，我应该转发我的 SPA 收到的 ID 令牌和访问令牌吗？只是访问令牌？或者我应该为我的后端 REST API 设置不同的授权服务器，并让我的 SPA 访问 另一个 访问令牌？

Answer 1

一些答案​​：

1. id 令牌只是对 SPA 的用户已通过身份验证的断言。如果要将角色放入令牌中，请使用访问令牌，其目的是授权

2. API 应该控制授权。您的 SPA 应该向您的 API 询问授权区域，API 可以根据访问令牌内容进行回答。您的 SPA 不应直接读取访问令牌。

3. 仅将访问令牌发送到 API，这是标准推荐行为

责任

一般：

• 用户界面可以决定显示哪些元素
• 当然，他们为此使用的数据需要来自可信来源
• UI 可以从 id 令牌中读取角色并使用它来控制要显示的内容
• 但 API 还需要角色信息，以授权请求

如果您想在 UI 和 API 中使用角色信息，则默认选项是将角色添加到 id 令牌和访问令牌中。

但是，这并不能很好地扩展，因为在一个真实的商业应用程序中，随着时间的推移，您可能会添加多个类似的规则，并且不断需要向令牌添加声明。

可扩展性

随着时间的推移更易于管理的更好选择是 UI 向其 API 询问角色和其他数据 - 因为无论如何 API 都需要相同的角色信息。

此外，令牌不必是 UI 和 API 做出授权决策的唯一数据源。我的blog post on claims 描述了一种模式，您可以使用它来管理来自多个数据源的声明。