Versions Compared

Old Version 6

changes.mady.by.user Nick Grosenbacher

Saved on

compared with

New Version Current

changes.mady.by.user Nick Grosenbacher

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • A user must be able to issue multiple access tokens

  • A user must be able to view metadata about their active tokens, e.g. scope, a custom name/identifier

  • A user must be able to revoke an individual access token

  • Generated access tokens must use scopes as defined in the OAuth 2 implementation

  • Generated access tokens should only expire if unused for 180 days or manually revoked

  • A client application should be able to access a token from a read-only key store and multiple, parallel client processes should be able to use the token without being concerned about concurrency issues.

  • Generated access tokens should be bearer tokens

    • A password/session token must not be required to use an access token

    • Functionality identical to OAuth access tokens is preferred

  • It should be impossible for any actor to determine the token other than the issuer at creation time (i.e. store a hash).

...

Service

Request Parameters

Response Body

Notes

POST /auth/v1/userGeneratedTokenpersonalAccessToken

Body:

AccessTokenGenerationRequest {

name: string (a unique-to-the-user, human-readable name. if unspecified, a UUID will be generated)

scope: Array<OAuthScope> (scopes granted by the token)

claims: OIDCClaimsRequest (claims granted by the token)

}

AccessTokenGenerationResponse {

token: string (A signed JWT access token.)

}

Generates a token that users can copy and paste into the command line client.

GET /auth/v1/userGeneratedToken personalAccessToken

None

Paginated list of AccessTokenRecord: {

id: unique ID of the access token

scope: Array<OAuthScope> scope of the token

claims: claims granted by the token

name: string, human readable name

lastUsed: the last time an access token was used

createdOn: the date/time the access token was created

state: enum (ACTIVE or EXPIRED)

}

Retrieves a paginated list of the user’s generated access tokens. Tokens that are active or expired will appear. Tokens that have been revoked (deleted) will not appear.

DELETE /auth/v1/userGeneratedTokenpersonalAccessToken/{id}

Path param:

id: the id of the token to delete

None

Revokes the token if it’s a valid access token.

DELETE /auth/v1/userGeneratedToken

None

None

Revokes all personal access tokens.

How to use a personal access token

...

What should the token look like? Some options

...

    • With or without additional userId header?

    Non-expiring, signed JWT (containing a an integer token ID and a user ID)

  • Opaque token

    • With or without additional userId header?

This is partially an implementation question. The ability to revoke tokens requires storing tokens or token identifiers in persistent storage. Performance is critical because a database lookup will be done for every authenticated request made by a programmatic clientusing one of these tokens.