Authorization Modes
An Application can obtain access to a gateway or Connector in several ways, which Axec calls authorization modes. Each mode ends the same way, with an Axec access token for one exact gateway or Connector. The modes differ in whose authority the Application uses and in how the Application authenticates to Axec.
Choosing a mode starts with one question: is the access on behalf of a User, on behalf of the Application itself, or on behalf of a User who is not present? Application Credentials explain how each kind of client authenticates, while this page explains what each mode allows.
User delegation
Section titled “User delegation”User delegation lets an Application act for a signed-in User. The Application sends the User to Axec, the User signs in, connects any upstream account a Connector needs, reviews the access being requested, and approves it, after which the Application receives a token that can act only within what the User approved.
Axec implements this with Authorization Code and PKCE, the flow defined by OAuth 2.1 and detailed in RFC 6749 §4.1 and RFC 7636. Both Public and Private clients can use it, so it suits browser assistants, desktop tools, and AI clients that cannot keep a secret.
Example: Alex asks a coding agent to open a pull request. The agent starts authorization, Alex signs in to Axec and connects GitHub, and the agent then calls the GitHub tools with Alex’s authority and nothing broader.
A delegated token normally depends on the User’s browser session. When a backend must keep acting after that session ends, the Application can request offline access, which adds a refresh token that Axec rotates and can revoke. See Request offline access for the details.
Autonomous access
Section titled “Autonomous access”Autonomous access lets an Application act on its own behalf, with no User involved. The Application authenticates with Client Credentials (RFC 6749 §4.4), so it must be a Private client that can keep a secret or private key, and Public clients cannot use this mode.
Because no User is present, an autonomous Application cannot use a User’s Connection. It can use only shared Vaulted Credentials and Connectors that need no authentication, and only for the Connectors it has been given access to.
Example: A nightly reporting agent reads shared tickets using an Workspace-managed API key. No one signs in when it runs, and it cannot reach Alex’s personal accounts.
See Connectors for how shared credentials work and Run an autonomous Application for setup.
Impersonation
Section titled “Impersonation”Impersonation lets a backend act as a specific User who is not present. The Application authenticates as itself, names the User it is acting for, and receives a token for that User’s access, so a background process can continue work that the User started earlier.
The mode is deliberately restrictive. It requires a Private client, because naming a User proves nothing by itself and an unauthenticated caller must never be able to act as someone else. The User must also have approved the Application beforehand through user delegation, and the token covers only what that approval allows. Axec records the Application as the actor in the resulting token, so activity remains traceable to both the Application and the User.
Example: Alex authorizes a scheduling assistant once in the browser. Later, the assistant’s backend uses its own credential to name Alex and read his calendar while preparing a morning summary, without Alex being online.
Impersonation depends on a prior authorization, which is the difference from autonomous access: the first acts with a User’s approved authority, and the second never uses a User’s authority at all.
How the Application authenticates
Section titled “How the Application authenticates”The mode and the client type are linked, because only some clients can authenticate strongly enough for each mode.
| Mode | Public client | Private client | User present |
|---|---|---|---|
| User delegation | Yes | Yes | Yes |
| Autonomous | No | Yes | No |
| Impersonation | No | Yes | No |
A Private client proves its identity with a client secret or a signed assertion, and a Public client relies on PKCE alone. Application Credentials describe each method.
Choosing a mode
Section titled “Choosing a mode”- Choose user delegation when the Application acts for someone who is present and can approve the access.
- Add offline access when that work must continue after the User’s session ends.
- Choose autonomous access when the work belongs to the Application and needs only shared credentials.
- Choose impersonation when a backend must act as a User who approved the Application earlier but is not present.
Service Accounts are separate from all of these. They automate Account management and do not give an Application access to Connectors.