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
I am trying to implement a "token-mediating backend" architecture described here.
In this architecture, the DPoP private key is owned by the browser. As such, it is the browser's responsability to send its DPoP proof while requesting a new token.
In the current implementation, openid-client only allows to provide a DPoP private key during the callback. It would be usefull to be able to forward a DPoP proof issues by the browser during this exchange (and let the browser retry when it fails).
In order to do this, all that is needed is to be able to provide custom headers (exchangeHeaders) in the client grant() method, in addition to the already existing exchangeBody. Would that make sense ?
Altering the class instance to do so might cause concurrency issues. Indeed, if two callbacks() are called simultaneously, they might both end up using the same headers (in particular in case of retries)
I know it's not ideal but you'll have to instantiate a new issuer.Client if you want to achieve what you're after, I don't think the cost of doing is prohibitive but also acknowledge it's a shitty pattern to suggest.
I don't have a better solution for now. I can see that in the future if such use case is prominent the DPoP option in the functions options might accept a function that could return the dpop proof to use itself.
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
-
I am trying to implement a "token-mediating backend" architecture described here.
In this architecture, the DPoP private key is owned by the browser. As such, it is the browser's responsability to send its DPoP proof while requesting a new token.
In the current implementation,
openid-client
only allows to provide a DPoP private key during thecallback
. It would be usefull to be able to forward a DPoP proof issues by the browser during this exchange (and let the browser retry when it fails).In order to do this, all that is needed is to be able to provide custom headers (
exchangeHeaders
) in the clientgrant()
method, in addition to the already existingexchangeBody
. Would that make sense ?Beta Was this translation helpful? Give feedback.
All reactions