-
Notifications
You must be signed in to change notification settings - Fork 103
The solid:oidcIssuer mechanism is unsafe #106
Comments
Interesting! That's a very good point. I didn't have external WebID functionality (hosted on a different server than the issuer) in mind when I proposed the Good catch. |
We might consider killing the “external WebID” functionality altogether. |
I was just thinking that.. |
Would that mean for WebID-OIDC authn your WebID and your authentication server, must live on the same domain? The core idea of WebID is that it can be hosted anywhere. |
Maybe we can do something where you specify in your WebID profile not just the authorized |
I would like to keep the functionality. Tim, Amy, myself, and some others use it.
Then we'd need some way to verify that. This information is currently not passed. |
Wouldnt your ID on the authn server be your WebID? How about this. When signing up, you would add the predicate, if it is not there already, else throw an error? |
True.. althoughhh... it would only need to be verified at signup, not with every authentication. So, you'd add another triple to your WebID Profile, be like, |
Why not make each subdomain created for users an issuer for that user, this way you would have simply BTW even if issuer stays |
I think @elf-pavlik makes a good point. I was just debugging some oidcIssuer problems with @RubenVerborgh I had set my oidcIssuer to the subdomain, but found out I need to set it to the root. Does it not make more sense to set it to the subdomain. Consider, also if a user wants to use a CNAME e.g. drive.user.com to point to their storage, for portability. Wouldnt they also want to point oidcIssuer to that CNAME? |
A totally different direction is to drop the issue mechanism altogether, and replace it with a |
OpenID Connect Discovery has a spec https://openid.net/specs/openid-connect-discovery-1_0.html Even though Solid doesn't use webfinger and instead of using defined in that spec I don't see exactly how you see using |
Chatted a bit to @dmitrizagidulin on gitter, a couple of things seem logical to me
We can break out the 2nd point into a new issue. EDIT: I actually thought part 2 was always the case, that you could EITHER type in your WebID or your IdP / nick |
As an aside, for those using the more secure WebID-TLS (which should be encouraged), the oidcIssuer predicate (which increases the attack surface) should not be needed. This is because all servers should be TLS capable, at least on one URI, so dont need to check the oidcIssuer, as the check is done in the TLS handshake. This gives users an upgrade path to a more secure and passwordless UX. |
Indeed, this is captured in nodeSolidServer/node-solid-server#755 |
If the user can retrieve its However (and it is a big one), the OIDC specification does not specify that the I do not know other identifiers specified by OIDC which could be used to link the WebID to the OIDC identity. |
I thought https://github.com/solid/webid-oidc-spec was the repo for WebID-OIDC stuff? @Sparika not sure you are describing the same thing but check my proposal on how WebID URI can be derived from the ID token: solid/webid-oidc-spec#10 |
For future reference, this is how CSS does it: https://github.com/solid/community-server/blob/e8a0f63e0284bd69d3c5b265ebf108ab3550434f/src/identity/ownership/TokenOwnershipValidator.ts Essentially by checking whether a randomized ID is present, and that ID corresponds to one specific pod (as opposed to an entire server). |
If your WebID is hosted on domain X, but your Solid pod is on domain Y ≠ X, then you need the following statement in your profile:
Unfortunately, this mechanism is broken. Consider the following example.
<#me> solid:oidcIssuer <https://solid.community>
to my profile.https://solid.community
can pretend to be me if they fill out my WebID upon registration.The text was updated successfully, but these errors were encountered: