Consider the following set up applications and services:

  • apps:
    • mycompany.com webapp
  • apis:
    • products api
    • orders api

mycompany.com's webapp uses OAuth2/openidconnect with an IdP (such as auth0) to authenticate a user, and a JWT token is returned. The webapp makes calls against these two public (but secured*) APIs. Consider over time other (3rd party) apps may be making calls against these APIs as well.

For API security, there are two primary considerations:

  1. the client making the call -- quota management, rate limiting, unique credentials for the client, etc.
  2. the user on whose behalf the call is being made -- I'd imagine the JWT returned from the OpenId Connect flow. Note in some cases there will not be a user (e.g. imagine a 'create user' call)

I'm struggling with these questions:

  1. is there a canonical way to implement client authentication separately from the user on whose behalf the request is being made?
  2. if the products api then calls the orders api (both public but secured), does the initial JWT just get passed through?

I have looked at mTLS for client-level auth but this seems to be better geared towards internal microservices rather than public ones. OAuth2 seems like a logical way to handle public API client authentication, but then it seems like I end up with two JWTs: one for the client, and one for the user.

Any advice would be much appreciated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.