代码之家  ›  专栏  ›  技术社区  ›  jmrah

ID令牌或访问令牌是否应用于授权SPA功能?

  •  0
  • jmrah  · 技术社区  · 4 年前

    上下文

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

    问题

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

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

    3. 当通过SPA调用我的后端API时,我应该转发SPA收到的ID令牌和访问令牌吗?只有通行证?或者我应该为我的后端restapi设置一个不同的授权服务器,并让我的SPA联系我吗 另一个 访问令牌?

    0 回复  |  直到 4 年前
        1
  •  2
  •   Gary Archer    4 年前

    一些答案:

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

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

    3. 只向API发送访问令牌,这是标准的推荐行为

    责任

    一般来说:

    • UI可以决定显示哪些元素
    • 当然,他们用于此目的的数据需要来自可靠的来源
    • ui可以从id标记中读取角色,并使用它来控制要显示的内容
    • 但是API还需要角色信息来授权请求

    如果希望在UI和API中同时使用角色信息,则默认选项是将角色添加到id令牌和访问令牌中。

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

    可扩展性

    随着时间的推移,一个更容易管理的更好的选择是UI向其API请求角色+其他数据,因为API无论如何都需要相同的角色信息。

    此外,对于ui和api做出的授权决策,令牌不一定是唯一的数据源。我的 blog post on claims 描述一种模式,可用于管理来自多个数据源的声明。