-
Notifications
You must be signed in to change notification settings - Fork 18
Proposal: recommend WebID OpenID Providers include redirect_uri in audience list to distinguish web apps #23
Comments
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. |
the point of having an application identifier in the id_token, rather than just using the by using the redirect_uri, placed into the id_token's presenting a signed id_token with an app identifier inside (as part of a proof of identity) is as strong as presenting an 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. |
@RubenVerborgh commented in #31 (comment)
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 |
In any case, we'd be overloading. Aren't there any fields available for extension? I don't think Side note: I thought that there was a need for registration for |
there is a need to register all
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. |
Thanks for clarifying!
Yes, but https://openid.net/specs/openid-connect-core-1_0.html says:
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.) |
i opened #33 for this. |
per #12 (comment)
or being the |
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
'saud
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
'saud
ience claim theredirect_uri
to which theid_token
orcode
was sent, if and only if thewebid
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 theid_token
. Therefore theredirect_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 theazp
" or "the audience that's a URI and that the user lists as a trusted application in her profile".The text was updated successfully, but these errors were encountered: