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

时间:2017-07-21 16:09:29

标签: api oauth-2.0 single-page-application openid-connect google-openidconnect

我有一个API服务器(资源服务器)和多个应用程序,Web GUI(SPA)和桌面客户端,可能还有更多。 除了我的API服务器的http基本身份验证之外,我还想使用openid-connect。 应该可配置哪个openid提供程序使用。我自己的脸书,谷歌... 我只想做身份验证,我不需要他们的API。我只需要一些个人资料数据,如电子邮件或名字。

我们说我已将google配置为我的IdP,而我目前正在使用我的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是用来访问google api的权利吗?但是,我也可以将每个请求传递给access_token到我的api服务器,api服务器调用https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=xxx来验证access_token并获取帐户名(邮件)。但这听起来不对,是吗?

我也有和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 个答案:

答案 0 :(得分:1)

您可以使用上面提到的所有三种方法,但实际上需要考虑一些因素。我会就可用的规格解释它们。

场景 - 两个系统 S1 S2

  • S1 - 身份提供商
  • S2 - API端点

您需要什么 - 信任并使用'代币'由 S1 发布,以访问 S2

对拟议解决方案的解释 A B C

A - 为每次通话验证S1发出的令牌

可以使用RFC7662 - OAuth 2.0 Token Introspection端点来完成此操作。此验证在规范中有效,因此您可以使用令牌验证端点。

此方法的优点在于,如果撤销令牌,则效果是即时的。下一个API调用将失败。但确实存在对性能的影响。您需要额外的验证服务电话。

请注意,您无需从此验证回复中获取帐户名称。它可以从ID令牌中获取,并可用于验证额外的保护。

B - S1为每次通话发出的信任令牌

现在,这种方法从RFC6750扩展 - OAuth 2.0授权框架:承载令牌使用。您确实可以使用ID toke对最终用户进行身份验证和授权。此link包含有关ID令牌用作持票人令牌的详细说明。

您确实可以使用MAC甚至加密来验证令牌的有效性。但请注意使用短期令牌并始终使用TLS。并注意令人耳目一新的令牌。因为根据openID连接规范,ID令牌不是刷新令牌请求的必需项。

C - 联盟的包装

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

如果您比这个解决方案领先一步,您可以尝试实现代码交换机制。您可以将令牌从外部交换到由您的某个系统内部发布的令牌(例如: - Google访问令牌到您的内部访问令牌)。这种方法的优点是您可以控制验证。此外,由于后续的令牌验证是在内部完成的,因此应该有性能改进。

希望这能解释您的疑虑。