Add cautionary notes about using blacklisted tokens with the default setting for JWT_TOKEN_ID.

It would be a breaking change, but I think we should consider making 'require' the default value at some point in the future, and perhaps drop support for 'off'.

Author: ashokdelphia

docs/index.md

@@ -189,6 +189,10 @@ There are two options for blacklisting tokens:
 
 When called, deletes all blacklisted tokens that have expired.
 
+### Warning
+
+Unless `JWT_TOKEN_ID` is set to `require`, blacklisting tokens will store the entire token value. This creates a potential problem if someone is able to read and delete records from the blacklist, either directly in the database or via the administrative interface. Note that the default value is `include`, not `require`. See the section on `JWT_TOKEN_ID` for how to migrate to requiring token id claims in all tokens.
+
 ## Additional Settings
 There are some additional settings that you can override similar to how you'd do it with Django REST framework itself. Here are all the available defaults.
 
@@ -357,6 +361,8 @@ For new installations, please override the default and set this to `require`, as
 
 For existing installations, when migrating from an older version (pre-1.17) or when changing the setting from `off`, we recommend setting this to `require` once all of the valid tokens have the id claims. This will typically be after `JWT_EXPIRATION_DELTA` has elapsed since upgrading or allowing id claims to be included.
 
+Note that when set to `off` or `include`, the blacklist functionality - if used - will store the entire token value, which would allow someone with access to the administrative interface, or directly to the database, to steal an otherwise valid token and remove it from the blacklist. Using `require` for this setting means that only token identifiers are recorded for the blacklist and not entire tokens.
+
 Default is `include`.
 
 ### JWT_AUDIENCE