Authorization
Bearer Authorization
Provide requires the presence of a bearer
API token to authorize most API calls. A bearer
API token is an encoded JWT which contains a subject claim (sub
) which references an authorized entity (i.e., the User
, Application
or Organization
). The authorized entity uses a signed bearer
authorization Token
to access one or more resources for which the Token
was authorized. Unless otherwise noted, all API requests must include a header such as Authorization: bearer <jwt>
.
Access/Refresh Tokens
In accordance with the OAuth 2.0 specification, when an entity is authorized and the requested scope
includes offline_access
, a refresh token is vended and returned on behalf of the caller. This refresh token is long-lived and can be used to authorize short-lived access tokens using the refresh_token
grant type on subsequent authorization requests.
This pattern is useful for machine-to-machine applications; a secure practice is to store the long-lived refresh token in a Vault instance (i.e., as a secret), read it into application memory during container initialization and then use it to authorize a short-lived access token. If the container remains running long enough for the access token to expire, the refresh token should once again be used to seamlessly authorize a new access token.
Encoded JWT
The standard and application-specific bearer
claims are encoded as JWT and signed using the RS256
(RSA Signature with SHA-256) or Ed25519
(Edwards-curve Digital Signature) algorithm.
Header
When verifying a JWT, the algorithm used for signing and an identifier referencing the public key to use for signature verification can be found in the alg
and kid
headers, respectively:
Additional details related to signature verification can be found here.
Payload
The encoded JWT will, in most cases, include an expiration timestamp (exp
) after which the token is no longer valid. A Token
issued without an expiration date (i.e., certain machine-to-machine API tokens) must be explicitly revoked.
The following payload illustrates how standard and application-specific claims are encoded in a bearer
JWT:
Claims
The following claims are typically included in the signed token payload:
Signature Verification
The encoded JWT is signed using the the RS256
(RSA Signature with SHA-256) or Ed25519
(Edwards-curve Digital Signature) algorithm. The following public key can be used to verify the signature:
Authorize Token
POST
https://ident.provide.services/api/v1/tokens
Authorize a Token
on behalf of a User
, Application
or Organization
Returns an authorized JSON formatted JWT with an offline-access
scoped long-term access_token
that serves as authentication for related requests.
The scope defined in the <JWT> passed for authorization will serve as the host entity. For example, if you would like to authenticate a user to work within an Application
, the <JWT> would be scoped for the target application and the user_id
would be passed in the body of the request.
This API can be used to authorize OAuth2.
Headers
Request Body
Authenticate User
POST
https://ident.provide.services/api/v1/authenticate
Authenticates a user with the given parameters.; returns a <JWT> scoped to the user provided
Request Body
List Revocable Tokens
GET
https://ident.provide.services/api/v1/tokens
Returns a list of tokens that can be revoked; revocable tokens only include those that are scoped for long-term access.
Headers
Revoke Token
DELETE
https://ident.provide.services/api/v1/tokens/:id
Revokes a previously authorized Token
Token
revocation may be necessary if the Token
has become compromised or otherwise requires invalidation. Revocation of a Token
should only be necessary on Application
or otherwise permanent issuances.
Path Parameters
Headers
Last updated