Common terms in access management

Throughout the documentation we use the following terms when discussing the concept of access management for API applications.

Grant / Access Grant

A grant represents the right to access a resource URL (such as WebSDK, VedHSM). A grant can have limited lifetime, depending on configuration (default is one year), and a grant has attached to it what application is allowed to use it, and what scope for that application was granted. A grant is issued by the authentication server in exchange for valid credentials.

The Venafi Configuration Console and API use the term grant. The web console uses the term access grant. These terms are interchangeable.

Access Token / Token

OAuth uses bearer tokens for API authentication. The authentication server will return one or more tokens as part of an issued grant. Tokens infer access rights, and have a (configurable) limited lifetime. See the Auth REST for token management section for more information about getting tokens.

The Venafi Configuration Console and API use the term access token. The web console uses the term token. These terms are interchangeable.

Refresh Token

A refresh token might be supplied as part of the grant returned by the authorization server, if configured. Access Tokens have limited validity, and to ensure they don't get too much exposure, they often expire before the grant expires. In that case, a refresh token will have been provided when the grant was issued, and this refresh token can then be used to obtain a new access token (and a new refresh token).

Application (Integration)

Before an application can request a token, the application must be registered with the server. Unknown Client IDs/Applications cannot request grants.

In theTrust Protection Platform web console, Applications and Application IDs are referred to as Integrations and Client IDs.

Applications can be created in the web console from the API Integrations Inventory.

Scope

To allow fine-grained control over what operations an application is allowed to perform, each API endpoint requires a particular scope, and when requesting a grant, an application indicates what scope it requires. This allows you to restrict risk even if the user credentials used to obtain the grant provide wider permissions.

The scope controls what category of endpoints may be accessed. For example, certificate or ssh, or statistics.

Learn more about what scopes and restrictions are available.

Restrictions and Privileges

Within a scope, the caller is explicitly given the ability to do certain actions based on their privileges and restrictions.

If no privileges and restrictions are given for a particular scope, the caller will have read access to the related endpoints.

For example, a caller with the scope of certificate and no privileges and restrictions will be able to read certificate data, but will have no ability to take any actions. For the certificate scope, a caller can be given any combination of the following privileges and restrictions: approve, delete, discovery, manage, and revoke.

Other scopes have their own list of privileges and restrictions that can be granted for an identity.

Learn more about what scopes and restrictions are available.

Session cache size

You can limit the number of active sessions by setting the session cache size. In the web console, this is also called session pool size. When the cache size reaches it's limit, the oldest sessions are removed. A caller would need to refresh their token to access the application again.

Credentials

To obtain a grant, the authentication server requires credentials. The authentication server can be configured to accept any of the following as valid credentials: