0

In my architecture, I have several internal services that need to communicate with each other. I also have a identity access management service that stores information about users, roles and (coarse-grained) permissions.

Components (not exhaustive):

  • Service A
  • Service B
  • IAM service

Rather than giving services A and B full access to each other via IP whitelisting, I would like them to run as users who are managed by the IAM service. So the services need a way of interrogating each other's roles and permissions. I've considered the following approach:

I create opaque API keys for the users that the services will be running under. I store them on each service. When service A calls service B, it passes its API key. Service B then calls the IAM service to validate the key and acquire information about service A's roles before processing the request. Service B caches its responses from the IAM service to reduce chattiness.

I've seen solutions that involve an API gateway, but this assumes that the traffic is coming outside the network. I do not want to redirect internal traffic to the outside just for the sake of converting opaque tokens to by-value JWTs.

Bill_Flanders
  • 563
  • 2
  • 7
  • 19

1 Answers1

2

Opaque by-value tokens are really intended for the following purposes:

  • Reducing token size to a minimum (for client efficiency)
  • Hiding the details of what claims a user has as they dont need to know
  • Forcing a lookup of the claims on each request (so you can revoke/change tokens instantly)

You are on an internal network so payload size isnt as big of an issue and you probably don't care about leaking claims to other services. If your claims arent changing often then opaque tokens probably arent needed. This means that your service simply needs to request an maintain a by-value token to access internal resources.

Thats not too bad.

If you do need to convert by ref to by value on every request, or you want to simplify the auth loop for consumers a proxy approach is best. This would intercept requests to your service and replace the by-ref token (or perhaps apikey) with a by-value token. The advantage here would be that you have more detailed control over usage of by-value tokens, and your clients dont need to care about your internal security infrastructure.

This approach adds more overhead in exchange for more control. Its also fine to call through this from your internal services.

I wrote a bit about the authentication proxy pattern on my blog.

undefined
  • 33,537
  • 22
  • 129
  • 198