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
If the authenticator fails to validate the provided JWT token the returned error is enriched with the contents of the jwt claims from the token. The claims contain user personal data such as names and email address. According to our policy such information is treated as sensitive data and we should not log it. We need a way to configure whether the error should be enriched or not.
Describe your ideal solution
The suggested approach is to have a new configuration value of type bool within AuthenticatorOAuth2JWTConfiguration which would tell Oathkeeper to enrich the errors with the data from the jwt claims or not. The default value of the new configuration can be 'true' in order to keep the current behaviour and in cases where the enrichement of the message is not desired it could be overridden to 'false'.
Workarounds or alternatives
Based on the current approach I couldnt think of other approach that can keep the current default behaviour and provide the new functionality
Version
Currently we use v0.38.25-beta.1, but will be upgrading to the latest version
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Preflight checklist
Describe your problem
If the authenticator fails to validate the provided JWT token the returned error is enriched with the contents of the jwt claims from the token. The claims contain user personal data such as names and email address. According to our policy such information is treated as sensitive data and we should not log it. We need a way to configure whether the error should be enriched or not.
Describe your ideal solution
The suggested approach is to have a new configuration value of type bool within AuthenticatorOAuth2JWTConfiguration which would tell Oathkeeper to enrich the errors with the data from the jwt claims or not. The default value of the new configuration can be 'true' in order to keep the current behaviour and in cases where the enrichement of the message is not desired it could be overridden to 'false'.
Workarounds or alternatives
Based on the current approach I couldnt think of other approach that can keep the current default behaviour and provide the new functionality
Version
Currently we use v0.38.25-beta.1, but will be upgrading to the latest version
Additional Context
No response
The text was updated successfully, but these errors were encountered: