当我正在撰写关于OpenID连接Angular的博客系列时，我正在使用一个名为angular-auth-oidc-client的OpenID连接的Angular库。该库用于实现OpenID connect隐式流，并对ID令牌和访问令牌进行客户端验证。
我的问题是：
由于Angular应用程序存在于浏览器中，该浏览器包含可被篡改的javascript文件，具有例如恶意用户。嗅探另一个用户访问令牌，禁用ID令牌验证，在浏览器中进行ID令牌验证是否毫无意义？我知道客户端使用ID令牌验证身份验证，但是在浏览器中完成后是否提供了任何安全性？
我的问题不是关于OpenID连接的规范，而是关于使用浏览器进行id令牌验证。我创建了一篇博文here，其中我在实际层面上解释了OpenID连接。
谢谢。
答案 0 :(得分：0)
您的API（API后端）应该为每个请求验证令牌。前端只生成令牌并将其添加到每个API请求中（请参阅HTTP拦截器）。
答案 1 :(得分：0)
ID令牌是一种安全令牌。 您的客户端（Angular应用程序）应验证OIDC提供程序发送的任何ID令牌以对用户进行身份验证。 如果未进行此验证，则会通过对恶意用户进行身份验证来使API暴露于安全问题。 有关ID令牌的详细信息，请参阅this specification。
访问令牌也是一个安全令牌，但您的客户端不应执行任何验证并使用它＆＃34;原样＆＃34;。 字符串通常对客户端不透明。 访问令牌的验证由资源服务器执行（例如，使用Introspection Endpoint或检查自包含访问令牌）。 有关访问令牌的详细信息，请参阅this specification。
答案 2 :(得分：0)
单页应用程序，SPA，唯一目的是为人类提供UX体验替代手动执行jillion curl命令以后端微服务。如果令牌验证失败，SPA应该为人类提供有意义的UX交互。
SPA正在参与认证交换。没有理由不承担验证令牌的责任。试图将该责任委托给其他地方是一种脆弱的做法，它不必要地扩大了认证交换中的参与者集。在任何分布式协作中，参与者越少越好。
答案 3 :(得分：0)
angular-auth-oidc-client中本身提到，不建议使用隐式流，因为其他更安全的选项（例如PKCE）也可以使用。
关于您的关于浏览器中ID令牌验证的问题，考虑到嗅探另一个用户的访问令牌，这不在前端安全性范围之内，因为这更多地是关于在身份验证机制中引入传输层安全性。请参阅此link，了解可以实施的PKI最佳做法。一旦完成了令牌嗅探，恶意用户就可以扩展并模仿原始令牌所有者的身份，即使令牌验证发生在您所告知的前端服务器中，我们也无法使恶意用户无效。 >