You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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").
The text was updated successfully, but these errors were encountered:
Throwing error.Token instead of errors.JWT and errors.Token... instead of errors.JwtToken..., the errors can then be handled by error_handlers for either jwt or token, token_... or jwt_token_... error types.
That way we could throw the new (token) errors, introduce new (token) error types, and deprecate the old (jwt) error types, allowing both during a transition phase.
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: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 counterpartjwt
andjwt_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 generictoken
andtoken_
error types from the JWT specific ones (cf. error "hierarchy").The text was updated successfully, but these errors were encountered: