2015-10-14 116 views
4

最近我一直在阅读微服务,特别是AuthN和AuthZ。大多数情况下,这一切都很有意义,我可以看到这一切应该如何工作。微服务中的身份验证和授权

对于我正在玩的东西,我会使用委托授权 - 所以我需要将令牌从客户端传递到服务,然后将相同的令牌从服务传递到服务。我还有一个OAuth2服务端点,它将接受令牌并返回令牌的详细信息 - 用户ID,有效期的开始和结束,令牌有效的范围等。

我遇到的问题是 - 为了正确地发出令牌,需要与用户服务进行一些通信,以确保令牌所用的用户实际上是有效的。并且为了验证令牌,需要与用户服务进行一些通信以确保用户仍然有效。然而,为了安全地与用户服务进行通信以获取关于用户的详细信息,需要一个令牌来授予此访问权限。

我假设有一些关于如何解决OAuth2和用户服务之间的循环依赖关系的标准做法,但我还没有看到任何提及。这是个常见的问题吗?还是我错过了一些明显的东西? (注意 - 现在我只实现了客户端凭证授予和资源所有者密码凭证授予,因为我只是在玩耍,看看它是如何工作的,而且他们更容易用cURL打电话。我不'但知道这有什么区别)

回答

2

是的,这有点鸡和鸡蛋的问题。不知道您对授权服务器有多少控制权,但解决此问题的一种方法是使用client certificates保护对用户信息服务的呼叫。

另一种方法是将用户信息服务和授权服务器合并到一个服务中,并且不需要一起调用。

+0

这是一个宠物项目,所以我完全控制了它。我只是在玩和学习:)把这些服务结合在一起我不愿意这样做,因为他们是不同的问题,但客户端证书选项可以工作,或者表明这是一个内部呼叫的其他方式。我假设这是一个已解决的问题,但其他人必须击中完全相同的东西 - 但我找不到任何关于它的内容...... – Graham

+0

如果您控制双方,您当然也可以拥有您的授权服务器为自己生成一个令牌来调用用户信息服务。 – MvdD

+0

因此,客户端调用oauth,oauth生成一个短暂的令牌并使用它来调用用户服务,用户服务然后调用回oauth来验证令牌,oauth只是隐式地相信它并让它去,然后用户服务继续并完成这项工作。我有点像。仍然有一些更细粒度的authz问题,但这并不算太坏...... – Graham