2:17 p.m.
Hi,
We are facing interesting OIDC challenges regarding sparsely featured OIDC
implementations.
One RP has an oAuth2 based implementation that never accesses the UserInfo
endpoint because (I freely quote the code comment) "They already have
everything they need to know from the id_token". It turns out, Google bloats
their id_token with claims so they reduce (effectively prevent) requests on the
UserInfo endpoint. It seems more and more RP's start to assume the token
endpoint will deliver everything they need or at least enough in the id_token.
We have decided to go along with the Googles of this planet and bend.
Now, pyop doesn't normally enrich the token endpoint id_token, but has a
parameter to consume extra_id_token_claims, just like the authhorizatoin
enpoint. From a satosa endpoint however, I have no access to the interal_resp
from the user to enrich the token endpoint. sastosa handle_authn_response does
set the authz database with the extra claims (consumed by userinfo endpoint I
guess) but I have no way to know the key (userid) to reliably access these
claims on the token endpoint and pyop doesn't have a authz code to userid
converter, as far as I know?
The best way I see, would be to modify pyop to enable internal (Provider
scope) extra_id_token_claims in the token endpoint. But we don't want to
maintain yet another fork in our deployment. This means that I'm allowed to
make a PR, but only if I have IdPy's commitment to merge the changes back
upstream.
Question: did I miss an option in pyop config that already does this? Or has
somebody already started an effort to implement this? If not: is IdPy willing
to merge this enhancement if I created a PR?
Best regards,
Martin