Microservices authentication.

I'm planning on adopting Global Authentication and Authorization as a part of Microservices (described in the image below, propriety of: https://dzone.com/articles/...).

Anyone has a different opinion? What are your thoughts on this one?

Looks generally solid. I like to use OIDC scoping, personally, but this would definitely work.

@SortOfTested a question if you don't mind, do you recommend using separate gateways for web and mobile or stick to one?

@gitpush different question: What would this bring? Microservices can become a dual wielded sword.

You already seperate (and fragment) a lot...

If scaling isn't necessary then I would say no.

@IntrusionCM Scaling is required and:
1. Services only need to authorize action and not care about authentication, they are responsible for their actions only.

2. centralized authentication and not repeating authentication code in each service

What does the Global Auth Module do which the Authn service doesn't?

Also, what credentials does the client provide to access service A (or any other service)? Isn't the JWT not sent to the client and only lives within the gateway and the services behind it?

@gitpush guess this was misunderstood.

I didn't mean to say your design was wrong. You applied - as far as I can tell from that screenshot - microservice architecture well.

I did answer your question: do two, seperate gateways make sense?

I inferred that you mean auth gateways.

Two auth gateways can make sense to prevent a SPOF, yes.

But - not necessarily - for two seperate "input streams" (mobile / web).

You could seperate that inside the gateway, If it is necessary, e.g. by tagging...

Two seperate gateways seem like a lot of pain without gain.

Scaling and safety wise, a single gateway would be an easier approach.

Scaling vertical is easier in the beginning... And less error prone.

Horizontal scaling can be cumbersome.

If necessary, I'd rather think about preventing the SPOF. And that can be very cumbersome in it's own.

Hope this clears it up

@gitpush
That's a question of scale. Dual gateways is tricky and should only be undertaken if you have specific security concerns that can't be handled with flags. It's a an abstraction that adds security and straight lines your authn story, but it also adds latency and complexity. You're also going to want to decide whether you want scope-based authx at the gateway or application tier.

I would look to Kong or tyk for minimal latency. If you need scale up scale down on a dynamic basis, you'll also want to have the entire thing wrapped in k8s.

@asgs Thatodule is for example active directory, where creds and users r stored. Yes authentication will be based on JWT

@IntrusionCM @SortOfTested thank you for your help it's clear now, Iget your concern about multi gateway and might drop it.

As for authorization, you agree on the part were each service handles it based on what auth service has included in token claims? Or do you know a better approach.

As for APi gateway, I'm exploring Ocelot, what do you think? I'm thinking of connecting Ocelot with service discovery to avoid bloated config files

@PublicByte I usually follow this: https://docs.microsoft.com/en-us/...

regardless of which language I use

As long as your architecture supports in-app user auth in Kubernetes, then you should be good.

@PublicBytes Not sure what u mean exactly...

But guess RBAC vs ABAC?

https://en.m.wikipedia.org/wiki/...

https://en.m.wikipedia.org/wiki/...

Take a look at the "See also" section, there are tons of variety depending on what / how the Access Control works (User / Token / ...)