Glossary
Short definitions of the protocol terms, Authio product terms and Dedicated plan terms used across the console and these docs.
The terms below appear in the console, in the tokens Authio issues and throughout these docs. Each definition is short and links to the page that explains the term in full. Product terms are written the way the console shows them: realm, client, consumer, role, scope, organization, account and resource server.
A–C
| Term | Meaning |
|---|---|
| Access token | The token an application presents to an API to show what it may do. Short-lived, with a lifetime set per client from 1 minute to 24 hours. See Scopes and claims. |
| Account | Your company on Authio: the subscription, the team that runs the console, the API secrets and every realm. See Core concepts. |
| Account role | What a team member may do in the console and the Admin API: Auditor, Developer, Admin or Owner. See Team and access. |
| acr / amr | Claims that tell your app how the person signed in: amr lists the methods used, and acr sums up their strength as 1, 2 or 3. See Multi-factor authentication. |
| Admin API | The API under /api/v1/admin that the console uses to configure Authio, open to your automation through API secrets. See Admin API. |
| AI advisor | The assistant in the console that reviews configuration and activity and proposes changes it never applies on its own. See Authio AI. |
| API secret | A credential for automation, issued under API Secrets: an API key sent in the x-api-key header, or a personal access token. See Team and access. |
| Audience (`aud`) | The claim that names who a token is for. An API refuses tokens whose audience is not its own. See Resource servers. |
| Audit trail | The record of every change made through the console and the Admin API: who, what, when and with what result, refusals included. See Audit and insights. |
| Authorization code | The single-use code an app receives after sign-in and exchanges for tokens, protected by PKCE. See Any OIDC client. |
| Back-channel logout | A signed logout_token that Authio sends to a client’s registered address whenever one of its sessions ends, so the app can end its own. See Sessions and SSO. |
| Billable event | What usage-based plans count: a sign-in that opens a session, or a token issued with the password or client credentials grant. Refreshes and failed attempts are not counted. See Plans and billing. |
| Capability | A feature a plan turns on, such as the AI advisor or MCP integration. A capability the plan does not declare is not included. See Plans and billing. |
| Claim | A field inside a token, such as sub, email or the person’s roles. See Scopes and claims. |
| Claim mapper | A rule on a client that adds a custom claim to its tokens from a constant, a user property, a role or a group. See Scopes and claims. |
| Client | An application registered in a realm. A confidential client keeps a secret, like a back end; a public client cannot, like a SPA or a mobile app, and must use PKCE. See Core concepts. |
| Client credentials | The grant a service uses to get a token as itself, with no person involved. See Machine-to-machine. |
| Client secret | The password a confidential client proves itself with. Generated by Authio and shown only when the client is created or the secret is rotated. |
| Connected account | An account at an external service, such as GitHub or Google Drive, that a user connects through a connection provider of the realm, so Authio can hand its token to your MCP server. See Connected accounts. |
| Consent | A person’s permission for an application to receive the scopes it asked for. Asked when the client requires it, and remembered afterwards. |
| Console | The web app where your team configures and operates Authio. See Console tour. |
| Consumer | A machine identity attached to a client, with its own credential, scopes and roles. See Core concepts. |
D–I
| Term | Meaning |
|---|---|
| Dedicated environment | A complete Authio deployment — API, console, database and cache — provisioned for one account after its payment is confirmed. See Dedicated environment. |
| Dedicated plan | The plan that buys a dedicated environment: no trial, a flat price per term, and no realms on the shared platform. See Plans and billing. |
| Delegation | A recorded permission for an application or agent to act on a person’s behalf, limited in scopes, in time and in how far it can be passed on. See Delegation. |
| Device flow | Sign-in for devices without a browser or keyboard: the device shows a code and the person approves it on another device (RFC 8628). See Device flow. |
| Discovery document | The public JSON at /realms/{realm}/.well-known/openid-configuration that lists a realm’s endpoints and what it supports. See OIDC endpoints. |
| Federation | Letting people sign in with an account they already have at Google, Microsoft Entra ID, GitHub, Apple or another OpenID Connect provider. See Social and enterprise sign-in. |
| Grace period | How long an account with an overdue payment keeps its users signing in before sign-in is paused. See Plans and billing. |
| Grant type | A way of requesting a token, such as authorization_code or client_credentials. Each client enables the ones it uses. See Core concepts. |
| Group | A named set of users of one client that passes its roles to every member. See Roles and permissions. |
| Hosted login | The sign-in, password recovery, consent and account pages Authio serves for each client, with the client’s branding. See Hosted login. |
| ID token | The OpenID Connect token that tells your app who signed in, when and how. See Scopes and claims. |
| Identity provider | A service that confirms who someone is. Each realm is one, and it can also accept sign-ins from external ones. See Social and enterprise sign-in. |
| Impersonation | A support feature that gives an administrator a token acting as a user. Off by default in each realm, recorded in the audit trail before the token exists, and limited to 15 minutes. |
| Introspection | A call an API makes to ask Authio whether a token is still active (RFC 7662). See OIDC endpoints. |
| Issuer (`iss`) | Who issued and signed a token. Each realm has its own, such as https://authio.api.hyperio.tech/realms/acme. See Core concepts. |
J–O
| Term | Meaning |
|---|---|
| JIT provisioning | Creating a user automatically on their first sign-in through an external identity provider, or linking them to an existing user by a verified email. See Social and enterprise sign-in. |
| JWKS | The set of public keys an API uses to verify a realm’s tokens, published at /realms/{realm}/protocol/openid-connect/certs. See Core concepts. |
| JWT | JSON Web Token: the signed, self-contained token format an API can verify on its own with the issuer’s public keys. |
| MCP | Model Context Protocol: how AI agents call tools on servers. An MCP server is a resource server, and Authio is its authorization server. See Protect an MCP server. |
| MFA | Multi-factor authentication: proving who you are with two or more different factors, such as a password and a passkey. See Multi-factor authentication. |
| OAuth 2.0 | The open standard that lets an application act on someone’s behalf without receiving their password (RFC 6749). |
| OpenID Connect (OIDC) | The identity layer on top of OAuth 2.0 that tells an application who signed in, through the ID token. See Any OIDC client. |
| Organization | One of your business customers inside a realm, with its own members, verified domains and sign-in options. See Organizations. |
P–R
| Term | Meaning |
|---|---|
| Passkey | A passwordless credential kept on the person’s device and bound to the site, which resists phishing (WebAuthn). See Passkeys. |
| Personal access token | A pre-generated key a person uses in scripts and pipelines, exchanged with the personal_access_token grant for a short-lived token that acts on their behalf. See Team and access. |
| PKCE | Proof Key for Code Exchange (RFC 7636): proof that the app redeeming an authorization code is the one that asked for it. Required by default. |
| Plan | What an account subscribes to: the quotas and capabilities it gets, and how it is billed. See Plans and billing. |
| Platform operator | A member of Authio’s own staff, who runs the platform with a reserved role no customer account can hold. See Team and access. |
| Push approval | A second factor in which a phone paired to the account receives the sign-in request, and the person approves it by picking the number shown on the sign-in screen. See Multi-factor authentication. |
| Quota | A ceiling a plan sets, such as the number of active realms. A quota the plan does not declare has no ceiling. See Plans and billing. |
| Reactivation | Bringing back an account whose subscription ended by choosing a plan again, through a link sent by email. See Plans and billing. |
| Realm | An isolated tenant and identity provider, with its own issuer, keys, users, clients and policies. See Core concepts. |
| Redirect URI | An address of your app that Authio sends the person back to after sign-in. Only registered addresses are accepted, compared in full. |
| Refresh token | A longer-lived token that gets new access tokens without a new sign-in. Issued only with the offline_access scope, and replaced on every use by default. See Sessions and SSO. |
| Resource indicator | The resource parameter a client sends to ask for a token for one specific API (RFC 8707). See Resource servers. |
| Resource server | An API or MCP server registered in a realm, whose identifier becomes the audience of the tokens issued for it. See Resource servers. |
| Revocation | Invalidating a token before it expires (RFC 7009). See OIDC endpoints. |
| Role | A named set of claims that reaches the tokens of whoever holds it, assigned directly, through a group or granted by a client or realm. See Roles and permissions. |
S–Z
| Term | Meaning |
|---|---|
| Scope | The name of a permission an application asks for, such as email or orders:read. See Scopes and claims. |
| Seat | A place on the account’s team. Each member and each open invitation holds one. See Team and access. |
| Session | The record of one person signed in to one client, cited by the sid claim of every token issued from it. See Sessions and SSO. |
| Signing key | The key a client’s tokens are signed with. Its public half is published in the realm’s JWKS, and it rotates automatically, every 90 days by default. |
| SSO (single sign-on) | Signing in once and entering the realm’s other participating clients without typing credentials again. Opt-in per client. See Sessions and SSO. |
| Step-up | Asking for a fresher or stronger sign-in before a sensitive action, by requesting it with acr_values and checking acr and amr. See Multi-factor authentication. |
| Subscription | The account’s recurring contract for a plan, processed by Stripe. Its status decides what the account and its users can do. See Plans and billing. |
| Suspension | A dated block on a person’s access, total or limited to some scopes or roles, that starts and ends on its own. |
| Token exchange | Presenting one token to get another (RFC 8693). Authio uses it for delegation and for connected accounts. See Delegation. |
| TOTP | A time-based one-time code from an authenticator app (RFC 6238). Console members use it as the second factor of their own sign-in. |
| Trial | The 14-day free period on the Basic plan that every account on the shared platform starts with, no card required. See Plans and billing. |
| User | A person who signs in to a realm. One user per person per realm, shared by the realm’s clients. See Core concepts. |
| UserInfo | The OpenID Connect endpoint that returns the current details of the person behind an access token, limited to its scopes. See OIDC endpoints. |
| Webhook | An HTTP call Authio makes to your endpoint when something happens, signed with HMAC-SHA256 and sent again when it fails. See Webhooks. |
| Welcome credit | A promotional credit earlier accounts received on their first purchase of a plan, applied to usage charges until it runs out. New accounts start on the trial instead. See Plans and billing. |