@@ -43,7 +43,9 @@ so some information might change depending on which version and branch you're us
4343 - [ Authentication methods] ( #authentication-methods )
4444 - [ Customizing OIDC verification] ( #customizing-oidc-verification )
4545 + [ Generate token] ( #generate-token )
46+ - [ Enabling optional token features] ( #enabling-optional-token-features )
4647 - [ Partial permission tokens] ( #partial-permission-tokens )
48+ - [ Include ` sub ` claim in access token] ( #include-sub-claim-in-access-token )
4749 + [ Use token] ( #use-token )
4850 * [ Policies] ( #policies )
4951 + [ Client application identification] ( #client-application-identification )
@@ -381,37 +383,47 @@ How these policies work will be covered later on.
381383If successful, the server will return a 200 response with a JSON body containing, among others,
382384an ` access_token ` field containing the access token, and a ` token_type ` field describing the token type.
383385
384- The generated access token will also contain a ` sub ` claim.
385- This value indicates the identity from the original identification input that was provided during token exchange.
386-
387386If the claims are insufficient, a 403 response will be given instead.
388387
389- #### Partial permission tokens
390-
391- It is possible to set up the server so it also returns tokens
392- if only some of the requested permissions are granted,
393- instead of returning a 403 response.
394- This can be useful for setups where the RS requires only one of the requested permissions to perform a request.
395- The disadvantage is that the client might receive a token
396- that does not have all permissions to perform the intended action.
388+ #### Enabling optional token features
397389
398- To enable this, start the UMA server with both ` default.json ` and ` enable-partial.json ` .
390+ Some token-related features are optional and can be enabled by adding extra configuration files
391+ when starting the UMA server, in addition to ` default.json ` .
399392
400393From the repository root:
401394``` bash
402- yarn start:uma -- -c ./config/default.json -c ./config/enable-partial .json
395+ yarn start:uma -- -c ./config/default.json -c ./config/< feature-config > .json
403396```
404397
405398From ` packages/uma ` :
406399``` bash
407- yarn start -c ./config/default.json -c ./config/enable-partial .json
400+ yarn start -c ./config/default.json -c ./config/< feature-config > .json
408401```
409402
403+ #### Partial permission tokens
404+
405+ It is possible to set up the server so it also returns tokens
406+ if only some of the requested permissions are granted,
407+ instead of returning a 403 response.
408+ This can be useful for setups where the RS requires only one of the requested permissions to perform a request.
409+ The disadvantage is that the client might receive a token
410+ that does not have all permissions to perform the intended action.
411+
412+ To enable this, use ` enable-partial.json ` as the feature config.
413+
410414With this enabled:
411415- If at least one requested permission can be authorized, the AS returns ` 200 ` with an access token.
412416- If not all requested permissions are granted, that response body includes ` partial: true ` .
413417- If no requested permission can be authorized, the AS returns ` 403 ` .
414418
419+ #### Include ` sub ` claim in access token
420+
421+ By default, generated access tokens do not include a ` sub ` claim.
422+ To include it, use ` enable-sub.json ` as the feature config.
423+
424+ With this enabled:
425+ - Generated access tokens include ` sub ` , set to the identity extracted during token exchange.
426+
415427### Use token
416428
417429When receiving the access token, the client can perform the same request as it did in the first step,
0 commit comments