使用openid connect进行身份验证spa和rest api

Question

我有一个API服务器（资源服务器）和多个应用程序、Web GUI（SPA）和一个桌面客户端，也许还会有更多。除了超文本传输协议之外，我还想为我的API服务器使用openid-connect基本身份验证。应该可以配置使用哪个openid提供商。我自己的，facebook，google...我只想做身份验证，我不需要他们的API。我只需要一些个人资料数据，如电子邮件或名字。

比方说，我已经将google配置为我的IdP，目前正在使用我的Web GUI（SPA）。我需要登录，没问题，根据https://developers.google.com/identity/protocols/OpenIDConnect我将用户重定向到google，获取我的授权码，Web Gui（SPA）从google获取id\u令牌和access\u令牌。

到目前为止没有问题，但现在SPA必须与我的API Server一起使用，API Server需要验证来自客户端（WebGui SPA）的每个请求（因为它是无状态的rest api），并且需要知道哪个用户实际上做到了这一点。

A.

所以google的access_token是用来访问google 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\u令牌等等。因此，我将有一个/api/tokensign，我可以将id\u令牌从google传递给它，api验证id\u令牌并为我的WebGUI（SPA）创建一个access\u令牌。这个新的access\u令牌可以作为载体传递给每个api请求。根据规范，这听起来是最好的解决方案，但我真的需要自己在API中实现oauth2吗？听起来像是一个沉重的补充，因为a和B也可以实现。

我的res-api需要对每个请求进行身份验证，那么A、B、C是正确的方法吗？请不要告诉我这是基于意见的，不是。使用oauth2/openid-connect进行身份验证的正确方法是什么？

Answer 1

您可以使用上面提到的所有三种方法，但确实有一些考虑。我将根据可用的规范解释它们。

场景-两个系统S1、S2

• S1-身份提供者
• S2-APIendpoint

您需要什么-信任并使用S1颁发的“令牌”访问S2

建议解决方案A、B和C的解释

A-验证S1为每个调用发行的代币

这可以使用RFC7662-OAuth 2.0令牌内省endpoint来完成。此验证根据规范有效，因此可以使用令牌验证endpoint。

这种方法的优点是，如果令牌被撤销，效果是瞬时的。下一个API调用将失败。但确实对性能有影响。您需要一个额外的验证服务调用。

请注意，您不需要从此验证响应中获取帐户名称。它可以从ID令牌中获取，并可用于验证以获得额外的保护。

B-S1为每个呼叫颁发的信任令牌

现在，这种方法是对RFC6750（OAuth 2.0授权框架：承载令牌使用）的扩展。您确实可以使用ID-toke对最终用户进行身份验证和授权。此链接包含有关ID令牌用作承载令牌的详细说明。

您确实可以使用MAC甚至加密来验证令牌的有效性。但请注意使用短期代币，并始终使用TLS。还要注意提神的代币。！因为根据openID连接规范，ID令牌不是刷新令牌请求的必需项。

C-联合的包装器

为此，您可以编写自己的解决方案或使用现有的解决方案（例如：-WSO2 identity server）。此identity server将配置为在您的应用程序上选择身份提供程序（客户端，如桌面应用程序或web应用程序）。Identity server将执行必要的重定向，并为您提供所需的令牌。但实际上，您需要使用内省endpoint来验证令牌的有效性。

如果您比这个解决方案领先一步，就可以尝试实现代码交换机制。您可以将令牌携带从外部交换到您的一个系统内部发行的令牌（例如：-谷歌访问令牌到您的内部访问令牌）。这种方法的优点是可以控制验证。此外，由于后续的令牌验证是在内部完成的，因此应该有性能改进。

希望这能解释你的疑虑。