Authorization Tokens

SPIRE uses biscuits to represent the authorization token. Typically, these tokens are kept private within the user interface but it is possible to get the SPIRE CLI (staging or production) to emit a biscuit for testing purposes within Postman or other tools.

spire auth status --authz emits the full biscuit for the currently authenticated user.

When the user interacts with the part of the Hub that is specific to a solution, a subscription-specific biscuit is generated, which is a trimmed version of the full biscuit, plus an additional field that provides information about the subscription.

spire auth status --authz --subscription <subscription ID> emits the trimmed biscuit. Subscription IDs can be determined from the output of spire auth status --decode

Token Parts

User Information

The user fact contains the user’s ID, email address, first name, surname and the user’s state, which should be active.

If the user is recorded as a member of an org, there will be an org fact, which consists of the organization’s ID and name.

Rights

A right in the authorization token defines a granted permission. There are a few different ways that a right might be represented.

right("spire", "sub:42df456d-8a4e-4e8c-b206-1a6e5468d82f", "seat", 15);

This fact represents a right that is for the spire service. It is targeted at a subscription as can be seen from sub:. 15 represents the CRUD operations permissible on a seat. It is a bit-wise field as follows:

(C)reate: 1

(R)ead: 2

(U)pdate: 4

(D)elete: 8

So 15 represents the full CRUD operations. In other words, this single fact states that the user can, against the specified subscription, perform:

• spire:seat:create

• spire:seat:read

• spire:seat:update

• spire:seat:delete

An example of a fact that defines a right targeted at a resource is right("css", "resource:36c277e9-78da-488a-b3db-bdf41e86d1ad", "sign:code");

This example also shows a permission that does not follow the CRUD pattern. So this fact equates to the permission css:sign:code, targeted at a specific resource.

It is also possible to have service admin seats and permissions. These essentially allow the specified permission to operate at the service level and therefore operate across all subscriptions and resources. An example of such a fact is right("spire", "org", 15);

So, the absence of a target string identifies a permission that is a service admin permission.

Subscription Fact

When the UI calls a service API, an additional fact is included in the trimmed biscuit to help identify the subscription being referenced in the API call. This avoids the need to pass the subscription ID as a parameter in the API payload.

subscription("sub:cdeebcfd-8f4a-4b06-968a-96cf82acbc95", "websites", "Linaro Website Access");

The fact defines the subscription ID, the slug ID for the solution and the name for the subscription plan.