How to combine security with the gateway?

Question

I'm investigating microservices architecture and now focusing on the api gateway along with security.

I found out that there are two different approaches:

1- Where authentication is outside of the gateway, meaning, the user

• has to authenticate first,
• gets the token,
• and then can make calls to the services via the gateway The most common scenario I've seen that everyone is implementing/presenting) as described on the diagram link Authentication outside of the gateway

2- Another way is to have everything behind the gateway, which means, user

• tries to access a secured resource/service via de the gateway,
• he's being redirected to the identity provider login page via the gateway as well,
• gets authenticated, the token is passed back to the client/user,
• and finally reaches the request service, everything through one http call via the gateway which will result in some additional calls (authorization code flow, url call back to the client, as described on the diagram link as well Authentication behind the gateway

And while some might speak about the 2nd approach, I can't seem to find any actual implementation or detailed description. Which makes me wanna ask ... why?

If I'm following a microservices design, I would naturally have the 2nd implementation, but no ... everyone appeared to be using the 1st one.

According to what I've read, yes, it takes more efforts since you'd have to reroute the necessary authentication and authorization endpoint, but is that it? Aren't there any other reasons which would make us favor the 1st one rather the 2nd one?

Any insights?

Answer 1

Short answer:

The second option is the most common. And you're right. If you don't need to redirect the user, don't.

Long answer:

Before microservices, all of the 'services' were different routes within a single application. The application routed user traffic to the right place.

Putting a gateway in the middle is abstracting that first level router from the single application to its own application.

• If the gateway is only routing traffic to backend services, then it's a load balancer (aka application aware proxy, reverse proxy, etc.) The load balancer is a frontend service that redirects traffic to the right internal backend service.
• If the gateway is both serving pages, and routing traffic to backend services, then it's a web application and a load balancer.

People who talk about authentication flows that use different user-visible targets (urls) are solving common problems. 3 reasons I can think of:

1. To make it really clear in diagrams which part is auth and which part is the black box service
2. As organizations grow, many people build their own services and auth flows. One for the first product, then another one for their next product, and a third for their third product. At some point they need to rationalize how to consolidate their auth into one flow.
3. Different URLs set different cookie scopes. Sometimes you need many domains to isolate cookies.

Example, take a service like Google Oauth or Okta SAML - you need to login on their domain, and you need a way to get the token back to your domain. Since you can't see google.com or okta.com cookies on yoursite.com, the external flows are necessary. This is often the case as companies add products that have different domains.

Google products redirect a few times every time you login. They are doing cookie management from accounts.google.com to gmail.google.com and keeping google.com cookies isolated the whole time. However, you're hitting the same google load balancer every time (or you theoretically you could).