>用户被重定向到身份提供者(例如Azure AD),进行身份验证,
>授权代码将POST回到我们的Web应用程序中的页面.
>然后,我们的Web应用程序使用授权代码从身份服务器检索刷新令牌,ID令牌和访问令牌.它们作为cookie存储在客户端上(HttpOnly标志设置为true).这是为了避免依赖于服务器的状态,以防用户通过负载均衡器路由到不同的Web服务器.
>当用户访问页面时,我们验证ID令牌的签名和有效期,并在我们的应用程序中针对用户数据库检查我们用于身份(例如电子邮件地址或UPN)的声明.
这有效 – 除了我们无法刷新ID令牌,因此用户在1小时后超时,需要重新登录.根据OpenID Connect规范,当使用令牌端点刷新令牌时,并非所有OpenID Connect提供商都将提供新的ID令牌.
我们目前看到的替代方案：
>根本不要使用ID令牌.使用访问令牌查询UserInfo端点以获取用户的声明,并将其缓存在服务器上(在缓存未命中时,例如,如果路由到其他Web服务器 – 只需使用cookie中提供的访问令牌再次请求UserInfo).由于访问令牌可以刷新,这可能会正常工作.
>优点：我们获得了一个经过适当刷新的令牌,由服务器验证.
>缺点：并非所有声明(例如aud和iss)都是由UserInfo端点提供的,至少对于Azure AD是这样.
>不要验证ID令牌的到期时间,只要它不早于例如12小时.
>优点：简单,只需要很少的努力就可以改变目前的行为.是否有我们今天也有的所有主张.
>缺点：可能存在安全隐患？评论？
那么在较长时间内持久保存用户登录的推荐方法是什么？使用UserInfo端点的访问令牌是一个合适的解决方案吗？
这取决于Identity令牌的使用方式.通常它只适用于客户.它允许客户端根据强制子声明对用户进行身份验证.它不应该用于授权.这就是访问令牌的用途.在混合流程(代码id_token)中,您可以在请求其他令牌之前检查用户的真实性.在这种情况下,小令牌最有效.
在授权代码流(代码)中,您必须使用代码请求令牌.它现在取决于id_token中的信息.如果id_token不包含配置文件声明,则您需要从UserInfo端点请求信息.
要访问UserInfo端点,您需要访问令牌.当您通过权威机构本身请求令牌时,丢失的aud和iss声明可能不是问题.在我看来,发行人和观众在那时都是众所周知的.
请注意,id_token不用于授权,因此不存在安全风险.即使id_token与资源共享也是如此.
规范要求您按照描述验证收到的令牌.但是当你没有收到新的id_token时,为什么要再次验证当前的id_token呢？它可能不是最新的,但它已经过验证.
所以IMO两种选择都很好,但我认为第一种选择更常见. id_token很可能在使用后被丢弃.因为访问令牌用于访问资源(包括UserInfo端点)和刷新令牌以刷新访问令牌.
一句话,用户的同意被用作过滤器.如果用户未同意个人资料信息,则根本不可用.