2

In a microservice architecture, an API gateway lays in front of the API. The purpose of this is e.g. changing some request / response parameters, for single entry point or checking authentication etc. Now I would like to protect my API using OAuth2 flows to obtain an access token. The problem is to decide who is the actual OAuth client, I will demonstrate it by using a SPA example:

a) Is it the SPA that started the oauthorize request (to the api gateway) by using the implicit grant. Then, the Api gateway would simply route the request through to the OAuth authorization server, acting as a single entry point, with the /authorize stuff from the implicit flow

b) Is it the API Gateway itself, meaning the SPA sends the username and password of the enduser to the api gateway (of course, here the SPA needs to be trusted with the end users credentials), which then acts on its own as an oauth client using the resource owner password grant

c) dismiss the api gateway at all and create the oauth authorization server "parallel" to the api gateway, meaning you would loose the single entry point etc.

The following picture demonstrate a very abstract architecture, and the question is about the numer "[2]", if this request is initiated by the SPA and passed through by the api gateway, or if the api gateway is intercepting the request and acting on its own as an oauth client?

OAuth with API Gateway

My guess is to always use the best fitting grant type for a specific client, regardless of an API gateway being in between or not. This would mean, that when it comes to OAuth, the API Gateway would simply pass the client authorization request through, whatever grant type it used. Therefore, [2] in the picture would come from the client, and not from the API Gateway acting as the OAuth client. Is this correct? As mentioned, this really gets tricky when it comes to first party apps as you probably could use the password credentials grant, which has huge drawbacks,e.g. no refreshing possible for SPAs.

pbeck
  • 107
  • 1
  • 6

2 Answers2

0

Please bear in mind that this is a purely opinion based answer, because your question is pretty vague.

I don't like the idea about using the API Gateway as the point which authenticates requests. I think that this defeats the Single Responsibility Principle. The gateways purpose usually is to expose your backend to external clients, perhaps change the contract for some specific clients, etc. But it shouldn't also authenticate calls. Besides it would have to do so based on the data passed to it, which you would have to gather somewhere else anyway.

Another thing which is I think undesirable, is that you're considering using the resource owner password grant for your SPA. This is not the correct use case for this grant flow. You could look into this article, which explains it much better than I could: https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications

I would suggest you use the Implicit grant type and use the api gateway to only route calls to the backend, don't authenticate the calls on that layer.

If you're using a spring cloud api gateway (essentially a zuul proxy), you will have to add proper configuration so that it forwards all security headers and redirects. This example works for me:

server:
    use-forward-headers: true

zuul:
    addHostHeader: true
    routes:
        <your oauth server route>:
            url: <your oauth server url>
            path: <if youve got any prefix>
            sensitiveHeaders:
            stripPrefix: false
Krzysztof Chris Mejka
  • 384
  • 5
  • 14
  • Hi chris, thanks for your response. The main goal is not to authenticate the users through the api gateway - is more like "is the api gateway the client for oauth server or the SPA and its request that just gets routed through the api gateway"? Because, when its the first one, you could use the ROPG, when its the second one, you should of course use an appropriate grant type like implicit flow. So what you (and I would also) do is for an SPA sending an implicit auth request to to the authorization server which of course passes the api gateway, but will simply be routed through? – pbeck May 07 '18 at 14:47
  • @pbeck I understand that your question is essentially "could I use the api gateway to authenticate a call when routing it to the backend?". And of course you could do that, but that's what I'm talking about mixing responsibilities. I don't think that this should be the purpose of the api gateway. What is more I'd advise you against using the ROPG, since it's for different use cases than yours. – Krzysztof Chris Mejka May 09 '18 at 07:21
  • Hi Chris, ok so I would go with, in this case, the implicit grant, that gets routed through the API Gateway to the OAuth Authorization server. This also means, that the OAuth server is behind the API Gateway and one single point of entry is given? I think this is related to https://stackoverflow.com/questions/49056708/is-keycloak-behind-api-gateway-a-good-practice – pbeck May 09 '18 at 08:56
  • Yes, that is what I would recommend. See my updated answer with some configuration proposition. – Krzysztof Chris Mejka May 09 '18 at 10:07
  • @pbeck I don't know what keycloack or kong is. Plus the answer in that question has got no arguments, so... it's kinda hard to argue with that. – Krzysztof Chris Mejka May 10 '18 at 12:03
0

It doesn't matter, what Krzysztof Chris Mejka in previous answer like or dislike. Take a look at BCP - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6

Latest recommendation from oauth working group at IETF is to use a kind of Api gateway/reverse proxy, another words - you need to keep tokens out of js entirely.

John Smith
  • 1,204
  • 3
  • 22
  • 42