8000
Customize DPoP verification behaviors on server to server invocations · keycloak keycloak · Discussion #40647 · GitHub
More Web Proxy on the site http://driver.im/
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
The new DPoP feature is a perfect piece to enhance the overall security. I'm trying to integrate it to our system.
However, I'm facing some complicated cases where
the user access token (issued by client A with DPoP) is used to invoke service A,
and inside service A, it uses the same user access token to invoke service B,
both service A and B verify the user authorization with Keycloak.
In this case, to invoke service B from inside service A, service A cannot generate a DPoP again for the user, because it's client A who owns the DPoP private key.
I'm trying to provide some customization here to support it. Such as, treating the access token of service A service account as a valid fallback of DPoP validation.
As I understand it so far, this kind of changes has to touch DPoPUtils, and the original classes will need to be replaced by the customized ones. This approach is not ideal in the long term. So, there are 2 requests -
The support for DPoP on server to server invocations
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi team,
The new DPoP feature is a perfect piece to enhance the overall security. I'm trying to integrate it to our system.
However, I'm facing some complicated cases where
In this case, to invoke service B from inside service A, service A cannot generate a DPoP again for the user, because it's client A who owns the DPoP private key.
I'm trying to provide some customization here to support it. Such as, treating the access token of service A service account as a valid fallback of DPoP validation.
As I understand it so far, this kind of changes has to touch
DPoPUtils, and the original classes will need to be replaced by the customized ones. This approach is not ideal in the long term. So, there are 2 requests -Thanks!
Beta Was this translation helpful? Give feedback.
All reactions