docs: update configuration doc

[skip ci]
panva · Aug 4, 2019 · f104796 · f104796
1 parent 7b010f4
commit f104796
Show file tree

Hide file tree

Showing 2 changed files with 5 additions and 5 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -1988,7 +1988,7 @@ _**default value**_:
 
 This option allows to configure the token serialization format. The different values change how a client-facing token value is generated as well as what properties get sent to the adapter for storage.
  - `opaque` (default) formatted tokens store every property as a root property in your adapter
- - `jwt` formatted tokens are issued as JWTs and stored the same as `opaque` only with additional property `jwt`. The signing algorithm for these tokens uses the client's `id_token_signed_response_alg` value and falls back to `RS256` for tokens with no relation to a client, when the client's alg is `none` or `HS***`. Note this is NOT an implementation of [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01) IETF draft but a proprietary format that will eventually get deprecated in favour of the aforementioned IETF format, once it gets stable and implemented that is.
+ - `jwt` formatted tokens are issued as JWTs and stored the same as `opaque` only with additional property `jwt`. See `formats.jwtAccessTokenSigningAlg` for resolving the JWT Access Token signing algorithm. Note this is NOT an implementation of [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01) IETF draft but a proprietary format that will eventually get deprecated in favour of the aforementioned IETF format, once it gets stable and implemented that is.
  - `paseto` formatted tokens are issued as v2.public PASETOs and stored the same as `opaque` only with additional property `paseto`. The server must have an `OKP Ed25519` key available to sign with else it will throw a server error. PASETOs are also allowed to only have a single audience, if the token's "aud" resolves with more than one the server will throw a server error.
  - the value may also be a function dynamically determining the format (returning either `jwt`, `paseto` or `opaque` depending on the token itself)   
 

diff --git a/lib/helpers/defaults.js b/lib/helpers/defaults.js
@@ -1183,10 +1183,10 @@ const DEFAULTS = {
    *   sent to the adapter for storage.
    *   - `opaque` (default) formatted tokens store every property as a root property in your adapter
    *   - `jwt` formatted tokens are issued as JWTs and stored the same as `opaque` only with
-   *     additional property `jwt`. The signing algorithm for these tokens uses the client's
-   *     `id_token_signed_response_alg` value and falls back to `RS256` for tokens with no relation
-   *     to a client, when the client's alg is `none` or `HS***`. Note this is NOT an implementation
-   *     of [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01)
+   *     additional property `jwt`. See `formats.jwtAccessTokenSigningAlg` for resolving the JWT
+   *     Access Token signing algorithm.
+   *     Note this is NOT an implementation of
+   *     [JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens](https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-01)
    *     IETF draft but a proprietary format that will eventually get deprecated in favour of the
    *     aforementioned IETF format, once it gets stable and implemented that is.
    *   - `paseto` formatted tokens are issued as v2.public PASETOs and stored the same as `opaque`