Access Control

Access control in Apiable authorizes your API consumers with OAuth2 scopes. Each subscriber receives a token carrying exactly the access their plan grants, instead of an all-or-nothing API key. For why this matters, see API security.

How does access control work in Apiable?

You connect your Authorization Server, define scopes for your APIs, assign them to a plan, and approve the access consumers request. Your Authorization Server then issues each subscriber a token carrying only the scopes they hold.

1. Connect an Authorization Server under Integrations → Authorization Servers.
2. Point your gateway at it. For a Gateway-bound plan, set the gateway's OAuth handler to Authorization Server on its Authorization tab.
3. Define scopes under Catalog → Resource Groups, and attach each scope to the APIs it protects.
4. Assign scopes to a plan on its Access Control tab, each as Active, Optional, or Restricted.
5. Handle grant requests under Consumers → Requests as consumers ask for Optional and Restricted scopes from the API Portal.

What do the Active, Optional, and Restricted states mean?

Each scope on a plan gets one state, which decides how a subscriber receives it. Every scope starts as Active, so every subscriber gets it until you change it.

Which authorization servers work with access control?

Keycloak, Auth0 and Duende IdentityServer. Amazon Cognito and Okta are listed as Coming Soon.

Duende connects for registration only: Apiable registers each subscription's client with the plan's Active scopes, but approved requests, revocations and cancellations need a manual step in IdentityServer. See Authorization Servers for the differences.

What do you need before you start?

The feature on your plan, a connected Authorization Server, a gateway pointed at it, scopes attached to your APIs, and a plan that uses an OAuth 2.0 client credentials method.

1. Scope-based access control on your plan, shown by Resource Groups under Catalog and Authorization Servers under Integrations in the sidebar.
2. A connected Authorization Server under Integrations → Authorization Servers, with the permissions its provider page lists.
3. For a Gateway-bound plan, its gateway's OAuth handler set to Authorization Server.
4. Scopes defined under Catalog → Resource Groups and attached to the plan's APIs.
5. A plan whose security method is OAuth 2.0 Client Credentials with Client Secret Basic or with Private Key JWT. Private Key JWT needs a Keycloak Authorization Server.

Where to start