Authentication and Authorization in Microservices
I've been reading a fair bit on Microservices recently, and especially around AuthN and AuthZ. For the most part, this all makes a lot of sense, and I can see how it all should work.
For what I'm playing with, I going with delegated authorization - so I'm to be passing tokens around from client to service, and then passing the same token on from service to service. I also have an endpoint on the OAuth2 Service that will accept a token and return the details of the token - the User ID, the Start and End of the validity period, the scopes that the token is valid for, etc.
The problem that I'm running into here is - in order to correctly issue a token, there needs to be some communication with the User Service to ensure that the User that the token is for is actually valid. And in order to verify a Token, there needs to be some communication with the User Service to ensure that the User is still valid. And yet, in order to safely communicate with the User Service to get details about a User, a Token is needed that gives permission for this access.
I assume there is some standard practice on how to solve this circular dependency between the OAuth2 and User Service, but I've not seen any mention of it at all. Is this a common problem? Or have I just missed something obvious?
(Note - for now I'm only implementing Client Credentials Grant and Resource Owner Password Credentials Grant, since I'm only playing around to see how it all works and they're easier to call with cURL. I don't know that this makes any difference though)
Yeah, that's a bit of a chicken and egg problem. Not sure how much control you have over the authorization server, but one way of solving this issue is to secure the call to the user info service using client certificates.
Another is to combine the user info service and authorization server into one service and eliminate the need for the call all together.
链接地址: http://www.djcxy.com/p/22276.html上一篇: 这种基于JWT的身份验证方法是否安全？
下一篇: 微服务中的身份验证和授权