@@ -28,6 +28,7 @@ so some information might change depending on which version and branch you're us
28
28
- [ Getting started] ( #getting-started )
29
29
* [ Starting the server] ( #starting-the-server )
30
30
* [ Authenticating the Resource Server] ( #authenticating-the-resource-server )
31
+ * [ Locating the Authorization Server] ( #locating-the-authorization-server )
31
32
* [ Resource registration] ( #resource-registration )
32
33
+ [ About identifiers] ( #about-identifiers )
33
34
* [ Resource access] ( #resource-access )
@@ -73,6 +74,16 @@ The RS uses that same key to sign its messages as described in the RFC,
73
74
using the [ http-message-signatures] ( https://www.npmjs.com/package/http-message-signatures ) library.
74
75
This is done for every HTTP request the RS sends to the AS in the following sections.
75
76
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
+
76
87
## Resource registration
77
88
78
89
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:
212
223
}
213
224
```
214
225
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.
216
228
217
229
#### Claim security
218
230
219
231
In the above body, the claim token format is a string representing a WebID.
220
232
No actual authentication or verification takes place here,
221
233
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 ` .
224
238
225
239
### Generate token
226
240
0 commit comments