Skip to main content

SecureAuth CIAM Concepts and Terms

SecureAuth uses industry-standard protocols to manage identity and access to resources. This glossary explains the key concepts in plain language, from basic authentication to advanced authorization.

Access Token​

An access token is a credential that represents permission granted by a user for an application to access their data. The user grants this permission during an OAuth 2.0 flow. SecureAuth issues the access token, which the application then includes with each request to prove it's authorized to access that data.

Application (Client and Service)​

In SecureAuth, applications fall into two categories:

Client applications are apps where users log in - like web portals, mobile apps, or enterprise applications using SAML. Users authenticate through SecureAuth to access these applications.

Service applications are backend systems and APIs that need to authenticate without a user logging in - like scheduled jobs, microservices, or integrations between systems. These use the Client Credentials flow.

Each workspace has its own authorization server. All applications within that workspace authenticate through that authorization server for user verification and access control.

Learn more about applications in Applications overview.

Authentication​

Authentication is the process of verifying who someone is. This happens when a user logs in - whether using a password, fingerprint, security key, or other method. SecureAuth supports various authentication methods, including multi-factor authentication (MFA) for extra security. Authentication proves identity, but it does not grant access to resources. That's handled by authorization.

Authorization​

Authorization is the process of deciding what an authenticated user or application can access. After SecureAuth verifies who you are (authentication), it checks your permissions and policies to determine what resources you're allowed to use.

The key difference: Authentication answers "who are you?" Authorization answers "what are you allowed to do?"

Authorization flow​

An authorization flow is a series of steps that lets an application ask a user for permission to access their data, and then get an access token to use that data. Different flows are designed for different types of applications.

Modern authorization flows:

note

The older Implicit Flow is no longer recommended due to security vulnerabilities. Authorization Code Flow with PKCE is now the standard for applications that run in browsers or on mobile devices. PKCE uses cryptographic verification instead of static client secrets, making it secure even when credentials cannot be safely stored.

Authorizer​

An Authorizer is a security component that controls access to your APIs. It sits at your API Gateway or Service Mesh entry point and makes real-time decisions about whether incoming requests should be allowed or blocked.

When someone makes a request to your API, the gateway asks the Authorizer: "Is this request allowed?" The Authorizer checks the SecureAuth authorization policies and the user's roles and attributes, then responds with allow or deny. This happens in milliseconds before the request reaches your backend service.

Why use an Authorizer:

  • Centralize authorization control across all your APIs and environments (AWS, Azure, on-premises, Kubernetes)
  • Manage authorization policies in SecureAuth instead of coding them into each service
  • Ensure consistent security rules across your entire system
  • Change authorization rules without redeploying code

SecureAuth works with Authorizers for popular API Gateways like Kong, AWS API Gateway, Apigee, Azure API Management, and Service Meshes like Istio.

For more information, see API Gateway authorization with SecureAuth.

Authorization Server​

An authorization server is the system that handles user login and issues tokens that allow applications to access user data. Every workspace in SecureAuth has its own authorization server.

When a user logs in to an application, the authorization server:

  • Verifies the user's identity (handles authentication)
  • Asks the user for permission to share their data (gets consent)
  • Issues an access token and ID token that the application can use

What you configure:

  • Which authentication methods users can use (passwords, passwordless, MFA, etc.)
  • Which applications are allowed to request user data
  • How long tokens are valid before they expire
  • Which data scopes applications can request
  • Authorization policies that control access

Each workspace can have its own separate authorization server, so you can configure different authentication and authorization rules for different groups of applications. For example, a banking workspace might require multi-factor authentication for customer access, while an internal workspace might use single sign-on (SSO) for workforce employee access.

For detailed configuration options, see Configuring authorization servers.

Brute-Force Protection​

Brute-force protection defends against attackers who try hundreds or thousands of password combinations to break into accounts. SecureAuth monitors failed login attempts and blocks accounts that exceed a threshold you set, preventing these attacks from succeeding.

For more information, see Brute-Force Protection.

BYOID​

Bring Your Own Identity (BYOID) means using your existing user directory instead of storing users in SecureAuth. This approach lets you keep user data where it already exists - in Active Directory, Okta, Auth0, Google Workspace, or other identity systems - while SecureAuth handles authentication and authorization.

SecureAuth includes pre-built connectors for popular identity systems. If your identity system uses OAuth 2.0 or SAML standards, you can use a generic connector. For custom systems that don't use these standards, you can build a custom integration.

Learn more in Identity Providers.

Claim​

A claim is a piece of information about a user or application - like their email, name, or role. Claims are included in access tokens and ID tokens, allowing applications to know who the user is and what they're allowed to do. For example, a claim might specify that a user has the "admin" role, which determines what resources they can access.

Consent is when a user grants an application permission to access their data. During login, the user sees a screen listing what information (called scopes) the application is requesting - like email, profile information, or contacts. The user can choose to allow or deny access. This consent is part of the Authorization Flow.

Extension Scripts​

Extension scripts are custom JavaScript code that runs during the authentication process. After a user authenticates through an identity source, the script automatically executes to modify or enrich the user data - like adding custom information, enforcing validation rules, or transforming user attributes before they're returned to your application.

For more information, see Extension Scripts.

Fine-Grained Access Control​

Fine-grained access control lets you set very specific rules about who can access what and when. Instead of just assigning broad roles, you can make decisions based on multiple attributes like user role, location, time of access, device trust, and resource sensitivity. For example, you might allow users to access an API endpoint only if they're in a specific region AND have authenticated with multi-factor authentication AND the resource has a certain sensitivity level. This attribute-based approach is also called Attribute-Based Access Control (ABAC).

ID Token​

An ID token is a security token that contains information about the user - like their user ID, email, and profile details (called claims). Applications use ID tokens to know who the user is after they've logged in. Unlike an access token (which grants permission to use resources), an ID token is specifically for identity information. ID tokens are created by the authorization server during OpenID Connect (OIDC) authentication flows.

Identity Provider (IdP)​

An identity provider (IdP) is a system that stores user information and authenticates users. When someone logs in, SecureAuth connects to the IDP to verify their credentials and retrieve their user data (like email, name, and other attributes). IDPs can be existing systems you already use - such as Active Directory, Google, Okta, or Auth0 - or Identity Pools within SecureAuth itself. This is different from an authorization server, which decides what authenticated users are allowed to access.

Identity Pools​

An identity pool is a built-in user directory in SecureAuth where you can store and manage user accounts. You can use an identity pool on its own or alongside external identity providers like Active Directory or Okta. Identity pools are useful when you want to manage users directly in SecureAuth or offer self-service registration to your users.

Learn more about creating and using an Identity Pool.

Identity Schema​

An identity schema defines what information you store about users in an identity pool and who can edit it. For example, a schema might include fields like email, name, and phone number, and specify whether users can edit their own information or if only administrators can change it. Schemas use standard rules (based on JSON Schema) to make sure user data is consistent and valid.

You can check how to configure and assign schemas in Configure Identity Pool user attributes.

Passwordless Authentication​

Passwordless authentication replaces passwords with something you have (like a security key, phone, or biometric) or something you are (like your fingerprint or face). Instead of remembering and typing passwords, you prove your identity using a device you own. Passwordless authentication is more secure than passwords because:

  • You can't accidentally give away your credentials to a phishing site
  • Your authentication happens on your device, not on a server storing passwords
  • It uses cryptographic standards like FIDO2 and WebAuthn that make it extremely difficult to compromise multiple accounts at once

When authenticating with SecureAuth, you can use WebAuthn instead of password-based authentication, provided this option is configured in your tenant.

JSON Web Token (JWT)​

A JSON Web Token (JWT) is a compact, digitally signed message that securely transmits information between parties. It contains three parts: a header (describing how it's signed), a payload (the actual information or claims, like user ID and role), and a signature (cryptographic proof that the token is authentic and hasn't been altered). JWTs are commonly used in authentication flows because they're self-contained. The receiving system can verify the token's integrity without needing to store it on a server. They can be signed using a secret key (symmetric) or a public/private key pair (asymmetric), depending on your security requirements.

Multi-Factor Authentication (MFA)​

Multi-factor authentication (MFA) is a security method that requires you to provide two or more different types of proof to verify your identity. For example, you might enter your password (something you know) plus a code from your phone (something you have), or use your fingerprint (something you are) along with a security key. MFA makes accounts significantly harder to compromise because attackers would need to steal multiple types of credentials instead of just your password.

Open Authorization (OAuth 2.0)​

Open Authorization (OAuth 2.0) is an industry standard protocol that lets users grant applications permission to access their data without sharing their passwords. For example, when you log into a service using your Google or Facebook account, that service uses OAuth 2.0 to securely request access to specific information (like your email or profile) rather than asking for your login credentials. OAuth 2.0 is the foundation for modern authorization flows in SecureAuth.

OpenID Connect (OIDC)​

OpenID Connect (OIDC) is a simple authentication layer built on top of OAuth 2.0. While OAuth 2.0 handles authorization (giving apps permission to access data), OIDC adds authentication (verifying who a user actually is). OIDC returns an ID Token containing user information (claims) in JWT format, so applications know who logged in. This makes OIDC ideal for scenarios where you need both user authentication and controlled data access.

PKCE (Proof Key for Code Exchange)​

PKCE (Proof Key for Code Exchange) is a security extension to OAuth 2.0 that protects public clients like mobile apps and browser-based applications. It prevents attackers from intercepting authorization codes and using them to gain access. PKCE works by having the application generate a random code verifier, send a transformed version (code challenge) to the authorization server, and then prove it has the original verifier when requesting an access token. This ensures that even if someone steals an authorization code, they can't use it without the verifier.

Policy​

A policy is a set of rules that SecureAuth uses to automatically make authorization decisions about who can access what. Policies let you enforce fine-grained access control by checking conditions like user roles, device trust, authentication method, or API endpoint before granting access. You can write policies using SecureAuth's visual editor (no coding required) or using Rego (an open-source policy language for more complex rules). Policies can be assigned at different levels - workspace, application, scope, or individual API endpoint - giving you precise control over your security.

Learn more in Authoring access policies using Rego or visual editor.

Role-based Access Control (RBAC)​

Role-based access control (RBAC) is a way to manage permissions by grouping them into roles and assigning users to those roles. For example, you might create an "admin" role with permission to manage users, and a "viewer" role with permission to only read data. Instead of assigning individual permissions to each user, you assign them to a role, and they automatically get all the permissions that role includes. This makes it easier to manage access as your organization grows.

Refresh Token​

A refresh token is a long-lived credential that your application stores securely to automatically get a new access token when the current one expires. Instead of asking the user to log in again every time their access token expires, your application presents the refresh token to the authorization server, which validates it and issues a fresh access token. This keeps the user's session active without interrupting their experience. Because refresh tokens are longer-lived than access tokens, they must be stored and transmitted securely.

Resource Owner​

A Resource Owner is a person who has data or resources that an application wants to access. For example, when you log into a service using your Google account, you are the Resource Owner—you own the account and the data in it. During login, you're prompted to decide whether to allow that service to access your information, like your email or profile picture. You grant or deny this permission during the authorization flow.

Security Assertion Markup Language (SAML)​

Security Assertion Markup Language (SAML) is an authentication protocol commonly used in enterprise environments to enable single sign-on (SSO). SecureAuth acts as the intermediary that connects to your identity provider (like Active Directory) and uses SAML to securely communicate with your applications. With SAML, you log in once through SecureAuth, and it automatically authenticates you to multiple applications without requiring separate logins. This approach is secure because SecureAuth sends digitally signed messages that applications can verify haven't been tampered with.

Scope​

A scope defines a specific permission that an application can request. When a user grants consent, they're approving the scopes the application asks for. For example, a scope might be "read email" or "write contacts" - limiting what the app can do even if the user approves the request. Scopes are part of the Authorization Flow.

A session cookie is a small piece of data that your browser stores while you're logged into an application. The cookie helps the application remember that you're logged in so you don't have to enter your credentials every time you navigate to a new page. Unlike other cookies that remain on your device indefinitely, session cookies are automatically deleted when you close your browser or log out, which makes them more secure for sensitive applications.

Single Sign-on (SSO)​

Single sign-on (SSO) is an authentication approach that lets you log in once with one set of credentials and automatically gain access to multiple applications without logging in again. For example, in an enterprise environment, you might log in to SecureAuth once in the morning, and then you can access your email, project management tools, and other business applications throughout the day without re-entering your password. This saves time and reduces password fatigue while improving security by centralizing how your identity is managed.

Token introspection​

Token introspection is a process where SecureAuth validates that an access token is legitimate and checks what permissions it grants. When an application or service receives an access token from a user, it can ask SecureAuth to inspect the token and confirm whether it's valid, who it belongs to, what resources it grants access to, and whether it has expired. This ensures that the application is trusting a real token from SecureAuth, not a forged or revoked one.

User portal​

The user portal is a self-service interface where end users can manage their account and control application access. In workforce environments using single sign-on (SSO), users can access all their enterprise applications through a single portal after logging in once. In consumer environments, users can view and update their profile, manage their authentication methods, and see which applications have permission to access their account. Users can also revoke access to any application at any time, giving them control over their data and privacy.

Developer portal​

The developer portal is a platform where developers and development partners can register and manage their own applications that integrate with your workspace. Developers can configure application details like redirect URIs and logos, set up authentication methods and permissions, and view all the necessary endpoints to connect their applications to your APIs. The developer portal enables you to allow external developers or partners to self-service their application setup without needing direct access to your workspace administration.

Workspace​

A workspace is a logical container in SecureAuth that organizes your applications with their own authorization server, identity sources, and access control policies. Each workspace operates independently with its own OAuth settings, user management, and security rules. This lets you manage different use cases separately, such as keeping employee applications in one workspace and customer-facing applications in another. You can create multiple workspaces within a single SecureAuth tenant to meet different compliance requirements, security standards, or business needs.