Token ID

[jirenius]

Issue

When revoking or updating a token previously set using a token event, it requires the service to keep track of all the connection IDs (cid) for which a specific token has been granted.

It should be possible to more easily update tokens belonging to one or more users, without the need to keep track of connection ID's.

Solution

In the token event, an optional parameter for a token ID (tid) string should be added. This value identifies the token, and is stored by Resgate on the connection together with the token. In practice, the token ID would often be the string representation of the user's identifier, such as user ID or username.

The updated token event with the optional tid parameter would look like this:

Connection token event

Subject
conn.<cid>.token

Sets the connection's access token, discarding any previously set token.
A change of token will invalidate any previous access response received using the old token.
The event payload has the following parameter:

token
Access token.
A null token clears any previously set token.

tid
Token ID used to identify the token on System token reset events.
MUST be a string.
May be omitted.

Example payload

{
  "token": {
    "userid": 42,
    "username": "foo",
    "role": "admin",
  },
  "tid": "42"
}

In addition, a new event should be added, that allows services to tell Resgate which token IDs should be updated:

System token reset event

Subject
system.tokenReset

Signals that tokens matching one or more token IDs (tid) are to be considered out of date.
A service MUST send an auth request to the provided subject for each connection with a token matching any of the token IDs.
The event payload has the following parameters:

tids
An array of token ID (tid) strings.
MUST be an array of strings.

subject
A subject string to which the auth requests should be sent.
May be the subject of an auth request handler, but it is not required.
MUST be a string.

Example payload

{
  "tids": [ "12", "42" ],
  "subject": "auth.authentication.renewToken"
}

Implications

• The feature requires a backwards compatible (patch) update to the RES service protocol

[jirenius]

Resolved in PR #205