My use case is almost solved by the access_control plugin, but instead of having a JWT created by an Application/Origin, I have a client JWT assertion that contains e.g. sub. The Client only sends the JWT during authn and receives an opaque Access Token.
client creates a JWT using a client secret (contains sub)
POST /auth on the Application with the JWT
Application returns opaque Access Token
GET /some-resource with the token
When the client requests the URL another time, the Access Token may have expired and it creates a new one. But the cache may be still hot enough. I wouldn't want the new token to cause a cache miss. Instead, the proxy should know which sub that Access Token was created with and add it to the cache key for lookup.
This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.
My use case is almost solved by the
access_control
plugin, but instead of having a JWT created by an Application/Origin, I have a client JWT assertion that contains e.g.sub
. The Client only sends the JWT during authn and receives an opaque Access Token.The flow is as follows (see also RFC7521, RFC7523):
sub
)When the client requests the URL another time, the Access Token may have expired and it creates a new one. But the cache may be still hot enough. I wouldn't want the new token to cause a cache miss. Instead, the proxy should know which
sub
that Access Token was created with and add it to the cache key for lookup.