Proposal: recommend WebID OpenID Providers include redirect_uri in audience list to distinguish web apps

[zenomt]

in #12, it was proposed to use the client_id to distinguish web apps. as discussed in that issue, there are multiple problems with using the client_id (most importantly, that it must be unique for every OP for every registration, and is therefore likely to be non-human-friendly and also different run-to-run in in-browser apps, so hard to track).

the redirect_uri used in OAuth/OIDC flows can be a (more) stable and (more) human-friendly identifier for an application that a user has consented to use.

to enable using the redirect_uri from an OAuth/OIDC flow as an application identifier and believably link it with the user's consent and use of that app, the OP must attest/sign to that effect.

Proposal: include a recommendation in webid-oidc-spec on the behavior of WebID-OIDC OPs to include the redirect_uri in the id_token's aud claim, perhaps by saying:

---

In order to enable reasonable discrimination of applications at a finer granularity than Origin, a WebID-OIDC OP SHOULD include in the id_token's audience claim the redirect_uri to which the id_token or code was sent, if and only if the webid scope (or other scopes whose semantics define this behavior) was requested by the client.

Some RPs might consider an unrecognized aud entry as an untrusted audience and reject the id_token. Therefore the redirect_uri will not be included unless the client has signaled a desire for its presence with an appropriate scope.

---

the redirect_uri can be extracted from the aud claim, for example by "the audience that looks like a URI" or "the last URI in the audience list" or "the audience that's a URI and isn't the azp" or "the audience that's a URI and that the user lists as a trusted application in her profile".

[zenomt]

deleted: i missed an important detail in this comment. nobody has reacted or responded so a delete seems prudent. my next message will correct my mistake.

[zenomt]

the point of having an application identifier in the id_token, rather than just using the Origin header, is for situations (like the AJAX/API/app/bot use case) where a Bearer access token is presented for authorization and the Origin header can't be trusted (because the presenter might not be the user's web browser).

by using the redirect_uri, placed into the id_token's aud claim by the OP, as an application identifier, the user only has to trust her OP (which she already does to vouch for her identity) to identify the app she's using.

presenting a signed id_token with an app identifier inside (as part of a proof of identity) is as strong as presenting an Origin header in a first-party cookie-based login session: the user trusts what's being sent, and the server trusts the user to identify the app she's using.

a benefit of using the redirect_uri over just the Origin would be that more than one app could be identified at an origin. this might be especially interesting in situations where the user has multiple browser-based apps stored in her own POD (which would be in the same origin), but wants to grant different permissions to those apps.

if the redirect_uri is used, there's nothing to prevent access control decisions being made on the origin of the redirect_uri. however, if only the origin of the redirect_uri is included in the id_token, then it's not possible to make finer-grained access control decisions if the user wants to.

[zenomt]

@RubenVerborgh commented in #31 (comment)

the redirect_uri should be the application identifier

Very likely not (talking from a SemWeb perspective now); the URI of a a redirect page identifies a redirect page, not an app.

here seems like a good place to continue discussing this point.

the (resource/entity located by the) redirect_url is what the user has actually consented to share her identity with, and is the only URL from the client configuration that is necessarily followed and loaded by the user's browser in an OIDC flow.

please see my previous comment above for why putting the full redirect_uri in the id_token is more flexible than putting just its origin in the id_token. also, putting the redirect_url in the aud is consistent with OpenID Self-Issued ID Tokens.

[RubenVerborgh]

In any case, we'd be overloading. Aren't there any fields available for extension?

I don't think redirect_uri itself is a good idea; perhaps a query string parameter to redirect_uri might work.

Side note: I thought that there was a need for registration for redirect_uri in some cases, which might not leave us that freedom.

[zenomt]

I thought that there was a need for registration for redirect_uri in some cases, which might not leave us that freedom.

there is a need to register all redirect_uris for your client, and whichever one you use must match exactly with a previously registered one.

Aren't there any fields available for extension?

there are no other fields or client claims that have the properties i mentioned above, particularly related to the user's consent and being followed&loaded by the browser. being followed/loaded from the user's trusted browser securely establishes its validity.

[RubenVerborgh]

Thanks for clarifying!

there are no other fields or client claims that have the properties i mentioned above

Yes, but https://openid.net/specs/openid-connect-core-1_0.html says:

Other parameters MAY be sent.

And the list does not seem to be exhaustive. (I might have picked the wrong section, but it seems like a general principle.)

However, I feel like we probably want to create an issue for the problem we are trying to solve, and work there on adding the desired attributes for a solution, and have separate solution threads. (Although I must say I do like this solution on a high level.)

[zenomt]

I feel like we probably want to create an issue for the problem we are trying to solve, and work there...

i opened #33 for this.

[zenomt]

per #12 (comment)

the redirect_uri can be extracted from the aud claim, for example by [... example ways ...]

or being the issuer of a proof-of-possession token. which i currently think is the best way.