0

Someone gets an access token from an IDP. I have an application (backend) that receives this in a request and verifies it against the IDP's published data (/userinfo Endpoint).

As I do not want to make a call to the userinfo endpoint every time a request comes in, I want to save the access_token as key with the value of the Token Endpoint Output with a TTL of the Token Expiry (in Redis). This way, I have a fast lookup time and do not have to request the userinfo every time.

Is there some type of security issue, or is this a common architecture? I could only find information on caching JWTs as blacklisting in the perspective of the IDP itself.

Edit:

I think it is called BFF Pattern. The React Frontend is the OIDC Client that handles the Refresh and Token Logic. The question is, that if an independent Backend (that uses the data in the token / from the /userinfo Endpoint) should implement Caching of the userinfo data or what the usual architecture is for this kind.

Improve this question
4
  • What do you mean by “someone gets an access token from an IDP”? Who is that “someone”? Isn't your application the intended OIDC client? Commented Oct 12 at 1:38
  • Warm welcome to the community. The complete minimal architecture is not quite clear to me. Commented Oct 12 at 11:26
  • Hello, I have a React App, that makes the request, sets a local storage token and does the refresh logic. I then have a Go Backend that makes the Database Calls etc. The React Frontend sends the JWT as Bearer in every request. There I want to verify the JWT and proceed with the Data (that the Backend requests from /userinfo), to make calls f.e. to a database. Is that clearer? Commented Oct 12 at 15:44
  • Keep access token, refresh token and ID token in encrypted cookies. Your backend service only has to verify ID token in memory by verifying its signature. You don't have to cache them. Commented Oct 13 at 11:48

1 Answer 1

Reset to default
0

This is all a bit oddly phrased, but I'll still try to answer it.

When you're dealing with identity providers and userinfo endpoints, then this is about the OpenID Connect protocol (OIDC), not just “JWT” (which is merely a token format that doesn't do anything by iself).

If your application is in fact the intended OIDC client, then you're supposed to cache the access token and any refresh token you receive from the token endpoint. However, those are sensitive credentials, so you should expose them as little as possible. Ideally, they should be kept encrypted unless you actually need them. Using the tokens as plaintext lookup keys creates additional risks and is entirely unnecessary, because you might as well use the pair of the iss and sub claims from the ID token as a unique user identifier. Those claims aren't sensitive, so they're much better suited for lookups.

As you also want to cache the userinfo endpoint response, be aware that claims aren't necessarily stable over time (with the exception of iss and sub), so the cached response may not always match the response you would actually get. This is completely unrelated to the access token expiry time (which only refers to the token itself). If you still want (or need) userinfo caching, then set a reasonable expiry time yourself, and don't rely on the cached data for anything critical. For example, the e-mail address can change at any time. When you actually want to send an e-mail to the user, make sure you get the most recent address from the userinfo endpoint.

Improve this answer
1
  • Hello, I have a React App, that makes the request, sets a local storage token and does the refresh logic. I then have a Go Backend that makes the Database Calls etc. The React Frontend sends the JWT as Bearer in every request. There I want to verify the JWT and proceed with the Data (that the Backend requests from /userinfo), to make calls f.e. to a database. Is that clearer? Commented Oct 12 at 15:44

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.