Is wrapping a third-party JWT in a app-signed JWT better for validation?

Question

I am trying to figure out the most effective way to validate a Azure AD JWT access token. In a database-less configuration, it seems like a huge cost to have every protected API request go and validate the JWT token using OpenID configuration then the Discovery Keys. It's just a lot of overhead.

I was thinking, why not just have your application create its own signed JWT and store the Azure JWT inside of it. Then your API's can very quickly validate it without any external calls.

Is this effective or a terrible idea?

Note: I've seen patterns where the application has a service that locally stores discovery keys and refresh them every 24hrs or so. I'd like to avoid this strategy and not rely on this type of job and database storage (hence the database-less comment).

Answer 1

In my opinion, it's not a good idea. All your APIs will have to manage key pairs to properly sign and verify JWTs. It will add unnecessary complexity to the solution.

I would rather seek possibilities for effectively caching the keys you need from Azure AD to verify tokens. Maybe you can cache them in memory, or even write to disk? This doesn't have to be a database. Also, usually, you don't need to refresh the cached keys. When you're validating a token and you can't find the proper key in your cache, then you can reach out to Azure AD and ask for new keys. That's how it is usually done.