Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

Added requirement for redirect URIs to be the same hostname as client #31

Closed
wants to merge 6 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion application-workflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ In this example, Alice is already logged into her identity provider (e.g. via so
2. DecentPhotos is an autonomous agent that runs on its own (from some cloud provider). To do this, Alice needs to give DecentPhotos some authority to access the photos in her pod on her behalf.
3. Alice goes to `www.decentphotos.example` to connect it to her pod. She enters her WebID so DecentPhotos can lookup who her IdP (Identity Provider) is, and clicks a 'Connect' button.
4. `decentphotos.example` (RP) reacts to the 'Connect' button being clicked by responding with a redirect. This redirect sends Alice's browser to the authorization endpoint at `alice.example` because it is her IdP, including in the request a client_id of the DecentPhotos application/agent WebID (`https://decentphotos.example/appid#this`).
5. Alice’s browser makes the request to the redirect URL (which is the authorization endpoint at IdP), identifying itself by the application WebID (client_id), and also passing along an optional scope and the redirect_uri, which is a callback to `decentphotos.example`, to be used after Alice has proved she has control of `alice.example` (RS)
5. Alice’s browser makes the request to the redirect URL (which is the authorization endpoint at IdP), identifying itself by the application WebID (client_id), and also passing along an optional scope and the redirect_uri, which is a callback to `decentphotos.example`, to be used after Alice has proved she has control of `alice.example` (RS). The redirect_uri MUST have the same host as the client_id.
6. Because Alice is already logged in at her IdP, she doesn’t need to enter her username and password again (she’s already got a token proving she is THE ALICE).
7. The authorization endpoint at `alice.example` (IdP) asks Alice if she wants to authorize DecentPhotos (RP) to access her Pod at a given scope. She has the ability here to further narrow this to only a subset of her photo library if she likes. Upon her confirmation here, DecentPhotos will be added as a trusted application in her WebID Profile, identified by its application/agent WebID (`https://decentphotos.example/appid#this`), and Alice's private photos folder at `https://alice.example/pics/private` will have its ACL updated to allow DecentPhotos (RP), identified by `https://decentphotos.example/appid#this`, read/write access to that folder and its contents.
8. Alice submits this and is sent (redirected) to the redirect_uri / callback which was provided by DecentPhotos (RP) in Step #5, along with an authorization code. Alice's browser now makes a new GET request to `decentphotos.example` (RP), with that authorization code included.
Expand Down
12 changes: 7 additions & 5 deletions example-workflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,9 @@ Relying Party (`bob.example`) have interacted, `bob.example` must dynamically re
itself *as a client/relying party* to `alice.example`. Bob's POD (in the RP role)
performs dynamic registration with Alice's POD (in the Provider role), and as
a result `bob.example` receives its very own `client_id` which identifies it
uniquely as a Relying Party to `alice.example`.
uniquely as a Relying Party to `alice.example`. The `client_id` MUST be identical to the host
of the client's `Origin` header (`bob.example`). This will be used later to validate
RubenVerborgh marked this conversation as resolved.
Show resolved Hide resolved
redirects.

If this is the first time a Provider and a Relying Party are encountering each
other, the RP must perform
Expand Down Expand Up @@ -122,10 +124,10 @@ verification.

*Example 1:* `alice.example`, in the Provider role, verifies the Relying Party
(`bob.example`) that initiated the authentication process, and redirects Alice's
browser to a pre-registered `redirect_uri` that `bob.example` provided during
the previous Dynamic Registration step. So, Alice's browser gets redirected
to `https://bob.example/auth-callback` (which is the URI Bob's POD uses as an OIDC
`redirect_uri` endpoint).
browser to a `redirect_uri` provided by `bob.example`. The `redirect_uri` MUST
have the same host as the application's `client_id`. So, Alice's browser gets
redirected to `https://bob.example/auth-callback` (which is the URI Bob's POD uses
as an OIDC `redirect_uri` endpoint).

(**Optimization**) The Relying Party may choose to establish a user session
(via a browser cookie), so that the user can skip Steps 1-5 in subsequent
Expand Down