search

solid / authentication-panel

GitHub repository for the Solid Authentication Panel
MIT License
11 stars 15 forks source link

Identity Broker Pattern #5

Closed jaxoncreed closed 3 years ago

jaxoncreed commented 5 years ago

Consider implementing the identity token pattern for resolving webIds

https://ldapwiki.com/wiki/Identity%20Broker

jaxoncreed commented 5 years ago

I'll expand on this a bit by document offline discussions between the Inrupt enterprise team and Justin Richer:

The point of the identity broker is to allow log-in to traditional OIDC systems without needing to modify those systems. Instead a broker sits in between and serves as the official IDP at least in the minds of the resource server. When you log into the traditional OIDC system, you are technically asking it to grant the broker access to your identity rather than the application.

Use case: Alice wants to log into decentphotos.com using her Google identity.

  1. Alice navigates to decentphotos.com and chooses "Log in with Google via Brokernet"
  2. A traditional Solid OIDC request is sent to brokernet.example with the redirect url, client public key, etc. These are stored on brokernet.
  3. Brokernet structures a request to Google's OP with it as the redirect_url in an authorization code grant request
  4. Alice logs into Google
  5. Google redirects back to brokernet with the authorization code which is exchanged for an id_token.
  6. Brokernet uses the information in the Id token to generate a WebID which it hosts on its own Solid storage Pod. 7 . Brokernet constructs a new token using the original redirect_uri and client public key from decentphotos as well as the new WebID
  7. Brokernet redirects back to decentphotos with the token.
elf-pavlik commented 4 years ago

This sounds like some UX sugar on top of brokernet.example acting as OP which possibly among other methods of authenticating user #27 supports 'login with google'. I think User should still be aware that Resource Servers will not really know about them using google account and will just identify them by WebID created by brokernet.example.

I think we could resolve this issue by writing Panel Finding describing this pattern, which parts of the system it affects (OP, app login screen, etc.) as well as some challenges eg. different apps could pick different broker OPs with 'google login' for their login screen and user could endup with multiple WebIDs without intending to have all of them.

jaxoncreed commented 4 years ago

This sounds like some UX sugar on top of brokernet.example

Agreed. This would be a possible implementation and would not need to be detailed in the spec.

elf-pavlik commented 4 years ago

I think this would better fit https://github.com/solid/user-lifecycle-panel since it deals with case where user starts using application but doesn't have IdP (very likely neither WebID or storage). I don't think this affects authentication directly. @kjetilk I think you created User Lifecycle Panel, would you see Use case described in this issue to fit there?

acoburn commented 3 years ago

This is a very useful idea but it is somewhat out of scope for the Solid-OIDC specification. This could, however, be revived as a concrete proposal.