OpenId / OAuth 2流程-使用AWS Cognito的场景

Question

​

​

我想向我的朋友们寻求一点帮助。

它本质上是关于openId/oauth流的，我对流类型有点困惑。

目前，我正在进行一个现代化项目，我需要为遗留组件和新组件建立一个新的身份验证/授权流程。

我的疑问是关于我应该做什么实现，以及我应该使用授权服务器中的哪些实现，即：

流1和流3

用户将向Web MVC应用程序提供登录凭据，它应该进行身份验证，并返回令牌。(1a / 1b) (3a / 3b)在后续与BFF 1/2和其他微服务的交互中，我将传递相同的令牌，对吗？在后端验证这个令牌的正确方法是什么？(4)

流程2

某些外部用户能够使用基本凭据(登录名/密码)通过API访问系统。在现代化的情况下，应该向他们指出什么？客户端Id /客户端密码？或者可以使用login / password来获取令牌吗？

非常感谢你的帮助

Answer 1

这些流都不是OAuth2，严格地说，您的图表没有任何与OpenID相关的内容。

在后续与BFF1/2和其他微服务的交互中，我会传递相同的令牌，对吧？

可以，您可以使用访问令牌或id令牌来授权将来的请求。

在后端验证此令牌的正确方式是什么？

cognito生成的标记都是非对称符号的JWTs。您可以使用任何JOSE/JWT库验证签名。https://jwt.io/在页面底部有一个很好的列表。Cognito目前不支持令牌内省，因此您的资源无法将令牌传递给cognito进行验证，如图所示。

某些外部用户能够通过使用基本凭据(登录名/密码)的API访问系统。在现代化的情况下，应该向他们指出什么？客户端Id /客户端密码？或者可以使用login / password来获取令牌吗？

这应该是客户端凭据授予。然而，Cognito的实现相当草率，并且不支持轮换秘密。此外，如果您依赖于ID令牌，则此授权类型不支持这些令牌。密码授予在技术上得到了认知的支持，但允许任何用户通过客户端使用用户名和密码进行身份验证。最好的选择可能是创建一个自定义身份验证质询，并通过它来处理您的身份验证。