Authorization Model

This documentation provides an overview of the authorization model used across the Fusebit platform.

Authorization is handled by the Fusebit HTTP API. The API requires that all HTTP requests include an Authorization header with a bearer JWT Access Token . Here is an example HTTP request to the API that illustrates the use of the Authorization header:

GET https://api.{region}
Authorization: Bearer {token}
Accept: application/json

The Fusebit Management Portal and Fusebit CLI provide alternative ways to work with resources in the Fusebit platform, and can often provide an easier user experience than the raw HTTP API. The Portal is great for authoring Integrations and managing their configuration and status, while the CLI lets you easily set up CI/CD infrastructure in order to integrate Fusebit into your devops pipeline. However, both of these tools ultimately use the Fusebit HTTP API, and implement the same authentication and authorization schemes that a developer might when using the API directly.

Accessing Resources of the Fusebit Platform

A valid JWT access token alone is not enough to ensure that a particular API request is authorized. A valid access token only grants access to the Fusebit platform as a whole, not any specific resource within the platform, such as a particular function, boundary or subscription.

Access to specific resources within the platform is managed via per-user access controls. User access to particular resources is given or taken away using the Fusebit HTTP API of the Fusebit CLI, more on that later.

Access is determined both by an action term and a resource path. For example, if a user had been granted the action integration:deploy on the resource /account/acc-9d9341ea356841ed/subscription/sub-9d9341ea356841ed/integration/chat-bot then the user would be able to deploy code to the chat-bot Integration in the given Account and Subscription.

Actions support wildcard segments. For example integration:* is a valid action to grant to user, allowing that user to perform all Integration-related actions. Resources also support implicit wildcard semantics. A resource path of /account/acc-9d9341ea356841ed/subscription/sub-9d9341ea356841ed/ would give a user access to all Integrations within the sub-9d9341ea356841ed Subscription.

Fusebit distinguishes between two different types of actors that access controls can be assigned to:

  • User : developers such as yourself and your team
  • Client: machine clients such as CI/CD infrastructure, or code executing as part of a backend API or other system

Introduction to Issuers

For a JWT access token provided by a User or Client to the Fusebit platform to be accepted, it needs to be issued by a trusted Issuer known to the system. Registering an Issuer requires providing the Fusebit platform with both the identifier for the Issuer and a means of acquiring the public key that can be used to validate the signature of access tokens from the Issuer.

The Issuer ID is usually a domain name or URL that uniquely identifies the issuer. For example, Google's OAuth 2.0 OpenId Connect Issuer identifier is ''. Auth0 assigns each Auth0 customer their own issuer id. The issuer id will be of the form: 'https://{customer-tenant-name}'.

As for a means of acquiring the public key, the Fusebit platform supports two different mechanisms:

  • Uploading a Public Key: One or more public keys for the Issuer can be directly uploaded to the Fusebit platform.
  • Hosting a Public Key: A public URL can be provided, at which a JSON file that contains one or more public keys for the issuer should be hosted. The JSON file can be either in the JSON Web Key Specification format (RFC 7517) or it may contain just a single JSON object with key ids as the object property names and the corresponding public key data as the property values. See Google's OAuth keys file as an example.

Which mechanism one uses will depend on the Issuer and the requirements one has regarding integrating with the Fusebit platform.

Registering an Issuer

To register an Issuer, use the fuse issuer add command in the Fusebit CLI.

Below is an example of directly uploading a public key to the Fusebit platform.

fuse issuer add --issuer \
                --publicKey ./ \
                --keyId 0ba34ef2-438a-4635-8f8b-86edec6aefdf \
                --name "Budgetly CI/CD Server"

The './' has the following content:

[omitted for brevity]

And for completeness, below is an example of using the hosted public keys mechanism.

fuse issuer add --issuer \
                --jsonKeysUrl \
                --name "Budgetly Auth0 Server"

Adding Users or Clients

After an Issuer has been registered with the Fusebit platform, adding a User or Client involves associating that user with a specific 'sub' claim value from the Issuer. For example, the user with the email [email protected], when signing in with Google, might be identified by access tokens that have a 'sub' claim value of google-oauth2|700634445110388888322.

To add a user, use the fuse user add and fuse user identity add commands.

Below is an example of adding the user John Doe, who is identified by the 'sub' claim value google-oauth2|700634445110388888322.

fuse user add John Doe [email protected]

> User added with user id: usr-341ea341ed9d9568

fuse user identity add usr-341ea341ed9d9568 \
  --issuer \
  --subject google-oauth2|700634445110388888322 \

Giving Access to Users or Clients

After a User or Client has been added to the platform, it will not initially have any access.

To give access to a User, use the fuse user access add command.

Below is an example of giving the user John Doe access to all Integrations in the Account.

fuse user access add usr-341ea341ed9d9568 \
  --action integration:*