Skip to content

Reference token AC #711

@johakoch

Description

@johakoch

E.g. for the "Use-once" tokens use-case, I'm thinking about a (non-JWT) reference token AC.
These tokens could be created (token endpoint) and stored (e.g. for a defined time) in a database by a (non-Couper) service, introspected (introspection endpoint) and revocated (revocation endpoint) by a client (Couper).

Couper acting as an OAuth2 resource server provides an access control using token introspection from #632.

The configuration could be quite similar to the jwt block configuration, but without the JWT-specific attributes:

beta_reference_token "rt" {
  cookie = "..."
  # OR
  header = "..."
  # OR
  token_value = ...
  # OR ...

  disable_private_caching = ...

  claims = {...}
  required_claims = [...]

  permissions_claim = "..."
  permissions_map = {...}
  # OR
  permissions_map_file = "..."

  roles_claim = "..."
  roles_map = {...}
  # OR
  roles_map_file = "..."

  beta_introspection { # mandatory
    # ...
  }
}

Quite some code could probably be reused/refactored from the JWT access control implementation.

However, there is at least one issue:
The error cases in the new access control would be very similar to the ones in the JWT access control (missing/invalid/expired). But currently the errors are called errors.Jwt... with their counterpart jwt and jwt_token_... error types. We cannot just rename existing error types (because they are part of the contract). And I'm not sure whether it is possible to derive more generic token and token_ error types from the JWT specific ones (cf. error "hierarchy").

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions