Auth as a standalone microservice

Hi everyone. I am looking at using https://github.com/aaronrenner/phx_gen_auth for a standalone auth service for authenticating users.

One thing I can’t wrap my head around is if I have multiple microservices that require an authenticated user in order to be called, how would I go about making requests to these services?

Example:

auth-service, service-1 (needs token to be called), service-2 (public), … etc.

Now, If I have an SPA built in either React or Vue, a user would authenticate via the auth-service, which also has its own database table (users). But now that the user is authenticated, what do I need to add to my other services that require authentication if they are completely independent from each other?

1 Like

Sounds like a perfect use case for JWT tokens. Pass the token along to other services. Other services just need to check that the token is valid.

1 Like

Thanks! I assume I would have to decode the token from the headers for all of my services - something like a plug maybe that’s present in every microservice?

1 Like

Yes, and you need to share a secret key among all services. If you use Guardian then everything you would need is included.

that sounds really cool. does sth like this exist already?

Thanks for all the advice so far! How would I handle associations with an Accounts table (auth-service) and for example, an Assignments table (assignments-service), where each assignment can have multiple accounts? Since I want those two services to be independent.

Would I have to duplicate models across my services?

Tables != services. You’ll encounter a lot of unnecessary complexity trying to make services “micro” to that level.

A JWT provides the service that receives it a cryptographically-verified proof that the request came from a browser that was issued the JWT, along with “claims” that describe the user. For instance, Guardian’s default subject_for_token function uses the ID of the user as the sub claim.

That ID will not be meaningful to the receiving service by default - either the service that’s issuing JWTs needs to expose a “get user info” endpoint, or the needed information should be included in the claims.

For instance, here’s a writeup that uses a roles claim to handle user authorization in microservices that use a JWT. (I’ve never used the particular product; it was the first hit for jwt claims microservices in Google)

OAuth2… At least if I understand this thread right.

what I understood was:
a standalone program that is responsible for auth only (eg implementing an oauth2-server).
So when I want to write an application I have zero auth-code in there and just connect to the auth-app eg per a Plug.

There is for example AWS Cognito. Its configured with the AWS console, eg you give it some styling for the login-screen. Then you can configure rules in your loadbalancer which paths should be authenticated by cognito. Very easy to setup.

I have also used Oathkeeper to handle Auth in micro services. It’s a proxy so your app does not need to do much, just read user info from jwt or a header

1 Like

@hungrydev is this similar to what you want to build? If yes, do it. I want this. :star_struck:

The standalone oauth2 server would be Hydra.
ORY is building this set of standalone Auth servers to build different Auth topologies with.

  • kratos - identity store (something like elixir pow)
  • oathkeeper - Auth proxy - can work with Kratos to support a session cookie, or as oauth2 app proxy,
  • hydra - oauth2 server (if you want to provide Google style oauth server)

ORY is impressive with care they put into making all these abstractions secure, although some of these apps are still under heavy development.
For example, Kratos is nice but GH issue list is long and we already bumped into few limitations (still no 2FA support for example). We plan to go back to pow/pow_assent and use hydra to let apps to integrate with our server.

2 Likes