Throughout the evolution of the TokenService, we've ensured that access tokens created in older versions remain valid in newer versions of ES. Effectively, upgrades should remain "unnoticable" to end-users and not affect their Kibana sessions; access tokens created before a version upgrade (or during, in case of a rolling upgrade) should remain valid after the upgrade.

As a result, there is a lot of code that handles BWC for legacy tokens. A guesstimate is over 20% of the entire class. This makes the service harder to understand, maintain, and evolve.

This issue proposes to remove BWC support code for tokens from ES versions older than 7.17. The rationale is:

1. Tokens are ephemeral and short-lived; they expire after at most one hour. As such, all the support burden is to effectively ensure a BWC window of one hour. After an upgrade is complete, new tokens are created according the format and rules of the new ES version.
2. To upgrade to 8.x from pre-7.17, customers must first upgrade to 7.17. 7.17 tokens remain fully compatible with 8.x.

The benefits of maintaining BWC in this case don't seem to justify the overall maintenance burden.

By removing BWC support, customers would only be impacted if they upgraded from pre-7.17 -> 7.17 -> 8.x in under an hour. The impact itself would be modest: end-users with "unsupported", still-active legacy tokens would have to repeat login. This holds for upgrades in ESS as well; an upgrade using the migration assistant involves a forced logout in Kibana already. As such, users actually performing the upgrade won't get affected by legacy tokens.

The code we should cut (there may be more):

• Handling tokens stored in the .security index (we introduced a dedicated index for tokens in 7.2)
• Handling tokens stored as UUIDs (also 7.2)
• Handling signed tokens (this is a big one; this code section and more could be cut entirely)