当我正在开发一个关于OpenID连接Angular的博客系列时，我正在使用一个名为angular-auth-oidc-client的OpenID连接的Angular库 . 此库用于实现OpenID connect隐式流，并对ID令牌和访问令牌进行客户端验证 .
我的问题是：
-
由于Angular应用程序存在于浏览器中，其中包含可被篡改的javascript文件，由具有例如的恶意用户 . 嗅探另一个用户访问令牌，禁用ID令牌验证， isn’t it pointless to do ID token validation in a browser ？我知道客户端使用ID令牌来验证身份验证， but does it provide any security when this is done in the browser ？
-
在请求资源API之前，它是否是更好的实现？ to not validate the ID token in the browser and instead use a front End server for validating ID token ？
我的问题不是关于OpenID连接的规范，而是关于使用浏览器进行id令牌验证 . 我创建了一个博客文章here，其中我在实际层面上解释了OpenID连接 .
谢谢 .
4 回答
您的API（API后端）应该为每个请求验证令牌 . 前端只生成令牌并将其添加到每个API请求（请参阅HTTP拦截器） .
ID令牌是安全令牌 . 您的客户端（Angular应用程序）应验证OIDC提供程序发送的任何ID令牌以对用户进行身份验证 . 如果未进行此验证，则会通过对恶意用户进行身份验证来使API暴露于安全问题 . 有关ID令牌的详细信息，请参阅this specification .
访问令牌也是安全令牌，但您的客户端不应执行任何验证并使用它"as-is" . The string is usually opaque to the client . 访问令牌的验证由资源服务器执行（例如，使用Introspection Endpoint或检查自包含访问令牌） . 有关访问令牌的详细信息，请参阅this specification .
单页应用程序，SPA， sole 的目的是为人类提供UX体验替代手动执行jillion curl命令以后端微服务 . 如果令牌验证失败，SPA应该为人类提供有意义的UX交互 .
SPA正在参与认证交换 . 没有理由不承担验证令牌的责任 . 试图将该责任委托给其他地方是不必要地扩大了认证交换中的参与者集合 . 在任何分布式协作中，参与者越少越好 .
它在angular-auth-oidc-client中提到，隐含流程现在不是推荐的选项，因为其他更安全的选项如PKCE可用 .
关于您在浏览器中进行ID令牌验证的问题，考虑到嗅探另一个用户's access token doesn' t来自前端安全性的范围，因为这更多是关于在身份验证机制中引入传输层安全性 . 有关可实施的PKI最佳实践，请参阅此link . 一旦我们完成了令牌嗅探，恶意用户就可以像原始令牌持有者一样进行扩展和冒充，即使令牌验证发生在前端服务器中，如你所说，我们也无法使恶意用户无效 .