OAuth2 flow understanding

2
votes

Im trying to understand how to secure my application. I chose to work with Auth0 to manage my users and apps.

I've seen this flow: API Auth

Im trying to understand this flow, but I miss something. Lets say I have web app, an API gateway, which trying to call an internal app, which is the resource server.

As I understand from the image flow:

  1. The API gateway app authenticates with the Auth0, and gets access token.

  2. The API gateway app calss the resource server with the access token.

Now I miss something, shouldnt there be anoter arrow, from the resource server to the Auth0, with the access token, to verify it or something?

Another question, to check if I understand, If I want to authenticate a user: 1. The user login with Auth0, gets the token.

  1. The user calls API gateway with the token.

  2. API gateway verifying the token with Auth0.

  3. API gateway calls the resource server

  4. Resource server verifying the token with Auth0?

Thanks :)

1
apisecurityoauthoauth-2.0auth0

1 Answers

2
votes

In general the API gateway handles the authentication and after that redirects/handles the request by performing, when applicable, additional requests to internal servers. The premise here is that the internal servers due to some type of network constraint are only accessible through the API Gateway and as such will not have to perform any additional validation of the authenticated identity - they trust the identity passed along by the gateway and assume that any necessary validation was already performed.

In this scenario, the API gateway is the resource server that receives and validates the tokens and the fact that it performs his duty by making additional internal requests it's an implementation detail.

Additionally, the verification of tokens can be done in one of two ways and only one implies communication between the resource server and authorization server:

  • validate the token by making an additional call to the issuer of the token and perform any decision based on its response.
  • validate the token in the resource server itself; the most common way to achieve this is to use a token format that can include information in the token itself (think JSON Web Token) and have that token signed by the authorization server (Auth0) in a way that the resource server can then validate the signature and be confident that the token contents were provided by the authorization server and not tampered.

As previously mentioned, this is the most common setup and assumes that any downstream server after the API Gateways is not publicly exposed and as such does not need to perform authentication decisions - aka token validation. These downstream server will probably still require a user identity in order to make additional authorization decisions, but they can receive this information in a different way than token and implicitly trust the information received.

If your downstream servers can also be accessed directly from an untrusted network this type of approach won't work, but if this is the case, you may also want to consider what do you gain by having an API Gateway in place.