我有一个API服务器（资源服务器）和多个应用程序，Web GUI（SPA）和桌面客户端，可能还会有更多 . 除了我的API服务器的http基本身份验证之外，我还想使用openid-connect . 应该可配置哪个openid提供程序使用 . 我自己的，Facebook，谷歌...我只想做身份验证，我不需要他们的API . 我只需要一些 Profiles 数据，如电子邮件或名字 .
让's say I have configured google as my IdP and I' m当前正在使用我的Web GUI（SPA） . 我需要登录，没问题，根据https://developers.google.com/identity/protocols/OpenIDConnect我将用户重定向到谷歌，获取我的授权码，Web Gui（SPA）从谷歌获取id_token和access_token .
到目前为止没问题，但现在SPA必须与我的API服务器一起工作，并且API服务器需要验证来自客户端（WebGui SPA）的每个请求（因为它是无状态的rest api）并且需要知道哪个用户实际上做了这个 .
A
所以谷歌的access_token是用来访问谷歌api的权利？但我也可以通过这个access_token与每个请求传递给我的api服务器，api服务器调用https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=xxx来验证access_token并获取帐户名（邮件） . 但这听起来不对，是吗？
B
我也有和id_token我可以验证，而不是每次都调用谷歌服务器 . 那么我是否也可以将id_token作为承载传递给我的api服务器的每个请求，并且api服务器可以验证id_token？但是根据openid-connect规范，access_token实际上是刚刚传递给api服务器并且id_token必须保留在客户端上的那个 . 但是id_token对我来说完全没用，API服务器需要知道用户是谁，客户端（Web GUI）并不在乎 .
C
或者因为它是我自己的API服务器，我的API服务器实际上是否需要自己实现整个oauth2系统，只是不进行身份验证，而是创建access_token等等 . 所以我有一个/ api / tokensign，我可以从谷歌传递id_token，API验证id_token并为我的WebGUI（SPA）创建一个access_token . 并且这个新的access_token可以作为承载传递给每个api请求 . 根据规范，这实际上听起来是最好的解决方案，但我真的需要自己实现oauth2到我的API吗？听起来像是一个沉重的添加，因为A和B也可以实现 .
我的rest-api需要对每个请求进行身份验证，因此A，B，C是正确的方法吗？请不要告诉我这是基于意见的，事实并非如此 . 使用oauth2 / openid-connect进行身份验证的正确方法是什么？
1 回答
您可以使用上面提到的所有三种方法，但实际上需要考虑一些因素 . 我将根据可用的规格解释它们 .
场景 - 两个系统 S1 ， S2
S1 - 身份提供者
S2 - API endpoints
你需要什么 - 信任并使用 S1 发出 S1 来访问 S2
拟议解决方案的解释 A ， B 和 C
A - Verify tokens issued by S1 for each call
这可以使用RFC7662 - OAuth 2.0 Token Introspection endpoints 来完成 . 此验证在规范中有效，因此您可以使用令牌验证 endpoints .
这种方法的优点在于，如果撤销令牌，则效果是即时的 . 下一个API调用将失败 . 但确实存在对性能的影响 . 您需要额外的验证服务电话 .
请注意，您无需从此验证回复中获取帐户名称 . 它可以从ID令牌中获取，并可用于验证额外的保护 .
B - Trust tokens issued by S1 for each call
现在，这种方法从RFC6750扩展 - OAuth 2.0授权框架：承载令牌使用 . 您确实可以使用ID toke对最终用户进行身份验证和授权 . 这个link包含对作为承载令牌的ID令牌使用的良好解释 .
您确实可以使用MAC甚至加密来验证令牌的有效性 . 但请注意使用短期令牌并始终使用TLS . 并注意令人耳目一新的令牌 . 因为根据openID连接规范，ID令牌不是刷新令牌请求的必需项 .
C - A wrapper for federation
为此，您可以编写自己的解决方案或使用现有解决方案（例如： - WSO2 identity server） . 此身份服务器将配置为在您的应用程序（客户端，如桌面应用程序或Web应用程序）上选择身份提供程序 . 身分服务器将执行必要的重定向并为您提供所需的令牌 . 但实际上您需要使用内省 endpoints 来验证令牌的有效性 .
如果您领先于此解决方案，则可以尝试实现代码交换机制 . 您可以将令牌从外部交换到由您的某个系统内部发布的令牌（例如： - Google访问令牌到您的内部访问令牌） . 这种方法的优点是您可以控制验证 . 此外，由于后续的令牌验证是在内部完成的，因此应该有性能改进 .
希望这能解释您的疑虑 .