Add token verification with previous public token

[oto-macenauer-absa]

Background

The login service endpoint is able to provide current and previous version of the public token however EventGate verifies the token only against the current version which means once a day the token expires and EventGate refuses requests as unauthorised.

During key rotation periods, tokens signed with the previous key become invalid immediately, causing service disruptions until clients obtain new tokens signed with the current key. The login service provides /token/public-keys endpoint specifically to expose both current and previous public keys to handle this scenario gracefully.

Feature

EventGate should use /token/public-keys login service endpoint instead of /token/public-key to be able to use both previous and current public token for verification.

This will allow seamless key rotation without service interruptions, as tokens signed with either the current or previous key will remain valid during the rotation window.

Example

Current behavior:

• Login service rotates keys at midnight
• User obtains token at 23:50 (signed with key version v1)
• At 00:01, login service rotates to key version v2
• EventGate fetches only v2 from /token/public-key
• User's v1-signed token fails verification → 401 Unauthorized
• User must re-authenticate to get new token

Expected behavior with fix:

• Login service rotates keys at midnight
• User obtains token at 23:50 (signed with key version v1)
• At 00:01, login service rotates to key version v2
• EventGate fetches both v1 and v2 from /token/public-keys
• User's v1-signed token successfully verifies against v1 key
• Token remains valid until its expiration time

API Response Format (from /token/public-keys):

{
  "keys": [
    {
      "key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    },
    {
      "key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    }
  ]
}