Skip to content

Commit 121330e

Browse files
committed
docs: Update getting started guide
1 parent 77a453b commit 121330e

File tree

1 file changed

+17
-3
lines changed

1 file changed

+17
-3
lines changed

documentation/getting-started.md

Lines changed: 17 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,7 @@ so some information might change depending on which version and branch you're us
2828
- [Getting started](#getting-started)
2929
* [Starting the server](#starting-the-server)
3030
* [Authenticating the Resource Server](#authenticating-the-resource-server)
31+
* [Locating the Authorization Server](#locating-the-authorization-server)
3132
* [Resource registration](#resource-registration)
3233
+ [About identifiers](#about-identifiers)
3334
* [Resource access](#resource-access)
@@ -73,6 +74,16 @@ The RS uses that same key to sign its messages as described in the RFC,
7374
using the [http-message-signatures](https://www.npmjs.com/package/http-message-signatures) library.
7475
This is done for every HTTP request the RS sends to the AS in the following sections.
7576

77+
## Locating the Authorization Server
78+
79+
To be able to communicate with it, the RS needs to know where to find the AS.
80+
The current implementation of the RS knows this through server configuration.
81+
This can be seen in the startup script in the [RS package.json](../packages/css/package.json)
82+
when looking at the `start` script.
83+
It uses the CLI parameter `-a http://localhost:4000/` to inform the RS where it can find the relevant AS,
84+
which internally sets the Components.js variable `urn:solid-server:uma:variable:AuthorizationServer`
85+
to the provided value.
86+
7687
## Resource registration
7788

7889
The Federated UMA specification requires that the RS registers every resource at the AS.
@@ -212,15 +223,18 @@ To make the request, the client performs a POST with the following JSON body:
212223
}
213224
```
214225
The `claim_token_format` explains to the AS how the `claim_token` should be interpreted.
215-
In this case, this is a custom format designed for this server.
226+
In this case, this is a custom format designed for this server,
227+
where the token is a URL-encoded WebID.
216228

217229
#### Claim security
218230

219231
In the above body, the claim token format is a string representing a WebID.
220232
No actual authentication or verification takes place here,
221233
meaning anyone can insert any WebID they want.
222-
This allows for easy testing and examples,
223-
but will be changed to an actual safe method, such as an OIDC ID token, in the future.
234+
This is great for quickly testing things out,
235+
but less good for security and testing actual authentication.
236+
The AS also supports OIDC tokens as defined in the [Solid OIDC specification](https://solid.github.io/solid-oidc/).
237+
In that case, the `claim_token_format` should be `http://openid.net/specs/openid-connect-core-1_0.html#IDToken`.
224238

225239
### Generate token
226240

0 commit comments

Comments
 (0)