Do we need to store local data in Couper for this? E.g. a map of tokens and last check? Or a list of revoked tokens?

Do we need to store local data in Couper for this? E.g. a map of tokens and last check? Or a list of revoked tokens?

In my proposal, in introspection_mode "interval", the response to the introspection request (containing the active property) is cached for a specified ttl (introspection_interval).
The cache key could be e.g. the token itself, or a combination of iss and jti (string identifier for the token) if available.

Additionally, revoked tokens (or, again, some identifier) could be stored, to further reduce traffic.

If token is JWT:

• if token is invalid (according to exp or other claims)
  • resource server denies access
• otherwise:
  • if cache entry exists for token in introspection response cache:
    • resource server grants/denies access according to cache entry's active property
  • otherwise:
    • resource server sends token to authorization server (introspection endpoint)
    • authorization server responds with introspection response (including "active": true/false)
    • if token is active:
      • resource server caches introspection response for token for configured TTL (if exp is known: maximum exp - unixtime())
      • resource server grants access
    • otherwise:
      • if exp is known and (either nbf is unknown or unixtime() > nbf):
        • resource server caches introspection response for token for TTL = exp - unixtime() (active state will not change, and after expiry the token is invalid anyway)
      • otherwise:
        • resource server caches introspection response for token for configured TTL
      • resource server denies access

In this case, it would be sufficient to cache only the introspection response's active property.

If token is opaque:

• if cache entry exists for token in introspection response cache:
  • resource server grants/denies access according to cache entry (active property and various claims properties)
• otherwise:
  • resource server sends token to authorization server (introspection endpoint)
  • authorization server responds with introspection response (including "active": true/false)
  • resource server caches introspection response for token for configured TTL (if response contains exp: maximum exp - unixtime())
  • if token is active and valid according to introspection response's claims properties:
    • resource server grants access
  • otherwise:
    • resource server denies access

In this case, the whole introspection response has to be cached.

Alternative configuration:

jwt "..." {
  # ...
  introspection {
    endpoint = "..." # the introspection endpoint at the authorization server
    backend = "..."  # or backend {}; for introspection request
    ttl = "..."      # duration; positive value: cache introspection response, otherwise do not cache
  }
}

Should this be a beta feature (beta_introspection block)?
Is attribute name endpoint ok? Or should it be introspection_endpoint (parallel to token_endpoint in oauth, but maybe redundant here)?

Token introspection is offered by e.g.

• Okta
• Connect2id
• IdentityServer
• Keycloak
• PingIdentity

VSCode: coupergateway/couper-vscode#132