In microservices it is not always required to assign strictly one responsibility to a service, as scope of microservices depends heavily on level of decomposition the business requirements, as well as technical capabilities that need to be offered by the architecture.
One of the hardest problems of planning for microservice architecture is authentication and authorisation. For the purpouse of clarification, it's worth to define authentication as determining if a given user (or a process) is what it claims to be, and authorisation as determining privileges that each authenticated user (or a process) is given within the scope of the system. Both Authentication and authorisation become harder in context of microservices operating independently in a common security context.
However, when designing serivces from scratch it makes sense to put some thinking into what range of capabilities each service is about to offer. In case of a common authentication microservice, it makes sense to define what "authentication" really means. In simplest case we can say the authentication pertains all activities related to "account security" but this still seems like a too broad set of capabilities. Instead it makes sense to limit the scope to "account authentication", that is making sure that given account credentials match secret authentication system covered by the authentication service. This reduces the capabilities to validating credentials and setting account credentials. If you think about it, resetting account credentials for existing accounts fails into category of setting the credentials for new accounts.
Having said that it is highly debatable whether authentication service should or should not host other than API services for providing services to end users, like web server, smtp server or sms gateway, or just generate secret codes used by other services in generating links or access codes used in web interfaces, confirmation e-mails or sms codes used in two factor authentication processes. Typically it makes much more sense for the authentication service to generate session identifiers, client tokens (like JWT) with a secret (including refresh tokens, where needed) and even public keys to be used by other services.
Typical authentication service provides API endpoints to generate or check a token as well as to handle user password resets (a forgot password workflow). Some example tasks include: a) getting tokens during authentication, b) requesting a user's profile using an Access Token, c) exchanging Refresh Tokens for new Access Tokens, d) requesting a challenge for multi-factor authentication (MFA). On the other hand typical user repository service provides endpoints for other services to check rights and manage user accounts, rights and role assignments.
There seems to be a circular coupling of authentication and user repository, as the first needs to ensure that a given login is still valid for a given user by checking in user repository if the user still exists. The user repository in turn needs to tell the authentication service if a new user is created so that authentication service understands their login credentials.
- Author
Maciej Zagozda
Company founder, and director of engineering.
- Comments
- Leave a Comment