Comments 3

  1. I’m working on a new project at my company and we are building several services that sit behind an API gateway. This is a somewhat new topic to me (I don’t have a lot of experience with Authentication/Authorization) so the diagram is very interesting to me. There are a couple of questions I have about it though… by putting the “Check Permissions” logic within the gateway – doesn’t that make your gateway much larger and couple it to the various micro services you have sitting behind it? I would have expected the gateway to require a JWT, but the actual “Check Permissions” logic to happen within each service, leaving each service as an autonomous process. For ex. in your model, if you add a new api to a service with a new permission requirement, you would have to update both the API Gateway and the service itself, wouldn’t you?

    Also, it seems like every request to the server will require a hit on both the authentication data store (to validate user), and on the authorization data store (to check permissions). Can you recommend any patterns for this that lightens the load on those data stores? For example, should the user information be cached to limit the number of database hits, or are there some patterns you could recommend?

    Thank you

  2. Jacob,

    Thanks for your question, let me give your check permissions questions a try. So our idea of an API gateway is that it is built for a given Application domain. I.e. a given application user interface will have a single purpose API gateway implemented. All the API routes in the API gateway would be for that application, possibly an accompanying mobile or other vendor integration access, but that’s it. It would not be used by other applications. The authenticated JWT token will contain user identity and valid access role information and the API gateway can then apply to the applications API route.

    So this allows applying role access at the API gateway communication to the UI appropriately… the UI can also call application API routes to determine what a user can or cannot do. The API gateway will be granted access to the service via TLS/mutual authorization… PKI type cryptography.. The JWT token will also be passed to the services responsible for data access and business logic… services can be reused across applications… and therefore API gateways…

    If you have a requirement to apply role access to business logic and data access, then yes, roles defined in the JWT token will have to be applied at the service level. So, these roles should be enterprise-wide since the service are. There is not any reason that Application-specific roles and service enterprise roles can’t make their way into the JWT tokens. So adding a new role-specific to a user of an application does not couple the service to this new role even though the role will be visible to the token.

    Regarding your authorization question: When the user logs in successfully, an access token is returned to the UI and is used and validated on each request from the UI to the API gateway. The token is used to create a JWT token for the API gateway and service. We have not had performance issues with this process happening on each request, and yes, you can use caching, etc. to speed performance. Also, a token timeout is traditionally applied, requiring users to re-login after a certain amount of inactivity.

    I hope this helps, please reply back with more questions if not.

    Thanks,
    David

  3. Jacob,

    Your intuition is correct on the idea of “caching” at the Auth layer… for example, using a Redis cache to maintain an auto-expiring “token” relationship to the user data is typical. This eliminates the potential load and time spent on the “data store” at each request that you referenced.

    As for “Check Permissions” logic…you may very well be able to eliminate authorization at the API Gateway, but there are also more complex scenarios where you may need it there also.
    We’ve had some specific scenarios that make this advantageous…for example:

    You sell your APIs via a “subscription” model and you have the following APIs:

    /api/v1/basicInformation – calls 1 downstream service to provide a response

    /api/v1/detailedInformation – calls 2 downstream services to provide a response

    If the user only has a “subscription” to /api/v1/basicInformation, then you can “short-circuit” the call to the downstream services (which would typically be reactively (async) called, therefore avoiding two unnecessary calls.

    Hope this helps.

    jaime

What Do You Think?