Our web app requires active user consent of our terms and conditions. When the user logs in, we check whether they already consented to the latest version of the conditions. If this is not given, the user needs to consent and won't be able to access any parts of the app or its APIs (although logged in correctly).
We are using OpenID Connect for authentication. I found the following properties that suggest you can require consent to custom conditions (see here):
tos_uripolicy_uriIs this meant for requiring consent to the client services conditions?
Should I create a custom claim for it? (-> The ToS might get a new version and need re-approval.)
Or alternatively: Is it possible to extend the OpenID Connect flow by showing a custom consent screen before calling the callback URI?
Is it possible to extend the OpenID Connect flow by showing a custom consent screen before calling the callback URI?
That is insecure and goes against the goals of OIDC
As a consumer of OIDC being provided to you, to allow you to have control over the appearance of consent would make it possible to show the end-user one thing and then have the OIDC provider sign the JWT claims with something else entirely.
It may be that you do not yet appreciate you are only party B and a three party relationship.
Party A is the end-client that gives consent to party C for party B to access the identity data party C controls. If you (party B) are given permission, you then know the identity of the end-client and OIDC will grant you additional data in a JWT that party C generated. The JWT is the mechanism Party C uses to assure you that they did the Authn to prove party A is who they claim to be, they are authentic and they assure you party B.
So you can not, and should not, be able to influence this process.
You should not assume the identity before the JWT is produced, so influencing anything related to identity breaks the security model, how can you be assured if you yourself influenced the outcome? it's nonsensical.
You should not be able to influence the permissions present to an end-client, because the end-client has not yet even decided if they give you permission!
Party C knows who the end-client is, they have an established relationship. You are using OIDC to get in the middle and leverage that trusted relationship, so you can trust the end-client is who they claim, and so you can get some personal identifiable information from party C about the end-client.
That is OIDC and your role in the flow, to be clear, you have no role or authority until after the OIDC flow is complete and you are given permission to even have a role that includes the end-client.
tos_uripolicy_uriIs this meant for requiring consent to the client services conditions?
This is for informed consent.
The end-client will still be show the same consent screen and maybe the OIDC provider will adjust the UI to show links to your ToS or Privacy Policy.
For example, outside OIDC protocol Okta allow you to create an application to be used for OIDC and in that Application config it has these attributes.
But during OIDC Okta do not adjust the UI to prompt the user to accept these terms at all, even last year Okta asked a client to add a bespoke field to represent consent.
I need to reiterate, as an OIDC consumer you can not and should not be able to directly customise the OIDC flow before you are given consent. But you might find a OIDC provider that agrees to configure their UI for you. It is up to them, the end-client has a relationship with the identity provider, you are actually in-practice requesting to get in the middle and leverage that.
Now commercially is a completely different circumstance. You pay the OIDC provider, which makes the OIDC provider financially motivated to assist you. It also means the security characteristics of OIDC are a conflict of interest if the OIDC provider is not more concerned with protecting the identity of the end-client than working with the party who pays the bills. Also, the end-user may not even be conscious that they have an identity established with an OIDC provider and a trust relationship, they may even believe it is only a 2 party relationship and not a 3 party and they decide if their identity is shared with you. This is also why developers of party B (you) misunderstand the 3 party relationship, and assume they have more control than they should based on the security characteristics of the OIDC protocol.
This commercial influence, end-client confusion, and implementation misunderstandings leads to the OIDC protocol not offering the intended security characteristics of the 3 party model and undermines the entire need for it. In most cases you do not need OIDC, particularly if the 3 party model is inconvenient and you wish to influence the consent more and the OIDC provider doesn't offer this, and maybe there are more elements you expect and want that OIDC is not providing, OIDC may not be what your business needs.