SecureAuth CIAM Concepts and Terms

An Access Token allows client application to access specific protected user's resources, based on Resource Owner's consent. The Access Token as such is an abstract concept, but in SecureAuth we always refer to the OAuth 2.0 Access Tokens. Access tokens are issued by an authorization server, such as SecureAuth, upon the successful completion of OAuth Authorization Flow. In most cases the token is represented by string and issued in the JSON Web Token (JWT) format.

In SecureAuth, Application is defined as a Client and Service. Client can be understood either as an OAuth 2.0 Client or as a SAML Service Provider.

The whole set of services in a SecureAuth Workspace constitutes the OAuth 2.0 Resource Server.

Learn more about apps in Applications overview.

A process that verifies who the user is. User can authenticate in many different ways, such as knowledge-based password authentication, possession-based passwordless authentication, multi-factor authentication (MFA), and more.

Authentication does not determine what privileges the authenticated entity has regarding protected data.

A security process that upon successful completion grants someone (authenticated entity/client/user) the privileges/permissions required to access specific resources.

A process of obtaining permission by an entity to access specific resource or perform actions on another entity's behalf. Depending on requirements (mostly on who/what is authorizing), there are several different flows, most common being Authorization Code Flow, Implicit Flow, or Resource Owner Password Grant Flow.

Authorizers are responsible for access control at API level. They act a localized policy decision point (PDP) integrated with and localized close to a policy enforcement point (PEP) like API Gateways. Authorizers are connected to the SecureAuth platform that acts as a policy administration point (PAP) and policy information point (PIP). The authorizer fetches the policies configured for APIs and services from the SecureAuth Platform. It allows for policy unification across different environments and API gateways in multi-cloud systems. It also allows for externalized authorization. When integrated, API gateways or Service Meshes can externalize the authorization to SecureAuth and its authorizers. When the request reaches the gateway, the gateway can invoke the authorizer, delegating access control to it. Authorizer and its built-in policy engine can evaluate the policy result and based on the outcome, deny or allow access.

For more information, see API Gateway Authorization.

The authorization server is an engine/system component that is used for minting Access and Identity Tokens (OAuth 2.0 and OIDC compatible) to enable secure data sharing between different web applications. SecureAuth's administrator portal allows for the configuration of authorization server capabilities, including grant types management, token settings, client registration, and client authentication. SecureAuth allows to create multiple authorization servers per tenant.

SecureAuth Authorization Server serves as a Policy Information Point (PIP) where the information on policies and their definition is stored to be passed to authorizers.

This is protection against unauthorized access to system/resource/API by large-scale attempts to guess password by trying different combinations (Brute-Force Attack). Thanks to logging the number of failed access attempts, SecureAuth can block an account that exceeds the defined request threshold. You can learn more in Brute Force Protection.

Bring Your Own Identity (BYOID) is a philosophy that SecureAuth strongly believes in. SecureAuth allows you to integrate the platform with your existing identity sources using open standards such as OpenID Connect and SAML.

To make it easier for you to integrate solutions, SecureAuth has a vast number of built-in Identity Connectors for major Identity Sources that allow you to quickly connect your Identity Source to the platform. If your Identity Source does not have a dedicated connector in SecureAuth , but shares identity information using either OIDC or SAML standard, you can use a generic OIDC or SAML connector instead. Most of the provided out of the box connectors comply with the OIDC standard, but you can also use the SAML generic connector to integrate your identity source in a SAML-compliant way.

Additionally, if your Identity Source is not following the OIDC or SAML standards, you can build your own custom connection or integrate SecureAuth with an external datastore. It requires more work on your side, but allows you to bring SecureAuth with its advanced authorization and governance capabilities into your system to make sure your applications and APIs are secure.

A piece of information e.g. about an authenticated user/entity that can be used in the authorization process. In order to pass data in authorization processes, claims are a part of Access and Identity Tokens.

The explicit action of a Resource Owner where they grant a list of scopes , which protect specific resources, to a third-party application. Resource Owner Consent is part of the Authorization Flow.

SecureAuth allows you to write JavaScript extension scripts in a convenient embedded environment so that you can modify the SecureAuth authentication context. Once written, you can enable the scripts on individual Identity Sources so that they are executed after user authentication.

Synonymous with Attribute-based Access Control (ABAC), Fine-Grained Access Control is a detailed control mechanism related to performing a specific operation within a system. More granularity (fine-grained) means multiple conditions are required for the user to access a particular resource.

The ID token is a security token that includes claims regarding the authentication of the user via OIDC provider. It is created on the authorization server’s side to encode the user’s authentication information.

Identity Provider is "a door to another resource" as it stores and manage identities. It is used in the authorization flow as a service to authenticate users and provides information about them.

Identity Pool allows for the persistent storage of user data within SecureAuth's infrastructure, thus providing the alternative to the Bring Your Own Identity (BYOID) approach typically used by SecureAuth SaaS tenants. Having added an Identity Pool to your tenant, you can connect it as an Identity Source to specific workspaces so that the end users can log in to SecureAuth (or register in the Identity Pool first).

In practice, Identity Schemas define user attributes (user-editable or editable by admins only). Technically, IIdentity Schema is a set of rules that is based on json-schema specifications and it defines and enforces the data constraints for the data payload within a pool that utilizes the schema.

You can check how to configure and assign schemas inStore Users.

Passwordless authentication is a way of protecting the user credentials by replacing the traditional, knowledge-based authentication (such as entering a password you know) to a possession-based authentication (such as confirming the login with your fingerprint on a device you own). The possession-based approach has a number of advantages, primarily:

The FIDO alliance is an organization trusted with maintaining the standards for passwordless authentication.

When authenticating with SecureAuth Identity Pools, you have the option to use WebAuthN instead of password-based authentication, provided that this option is configured in your tenant.

JSON Web Token (JWT) is an open standard that provides a secure way for authenticating data owners and transmitting information between parties using the JSON format. JWT is sent in the HTTP request with a digital signature. It can be signed either using a secret (with the HMAC algorithm) or a public/private key pair (with RSA or ECDSA).

A security measure that requires more than one form of authentication from independent categories of credentials to verify a user's identity. It means that, in addition to the base form of authentication, for example a password, the user has to provide another form of authentication, for example one-time password sent to the user's device.

A protocol that defines the process for third-party applications to access user's data managed by different services.

An extension protocol build on top of the OAuth2.0 framework that allows third-party applications to verify user identities and provide their profile information (as claims) in a JWT format (ID Token).

PKCE is an extension to the Authorization Code flow designed to prevent CSRF and code injection attacks, making sure that an Access Token is issued by OAuth 2.0 flows in a more secure way.

SecureAuth platform policies provide the multilevel authorization as the response to modern access control requirements. SecureAuth supports the Rego policy standard, but it also provides a native policy editor.

Policies are evaluated on several levels, starting from the entire worspace, down to a single API:

RBAC is a way to authorize Users by assigning them to roles which are mapped to permissions. Such a role defines the scope of resources the user may access.

Refresh tokens are long-lived tokens used to acquire a new access token when the present access token gets invalid or expires. They enable the client to get a new access token without prompting the user. The refresh token is a string of characters that represents the authorization granted to the client by the resource owner.

The owner of a resource that is being requested by third-party application. During the authorization flow, a Resource Owner is prompted to grant or deny access to their resource.

Identity protocol that uses XML as identity data format and HTTP/SOAP as transport mechanism. SAML enables the communication between Identity Providers and Service Providers using secure tokens, in order to enable access to multiple web applications using one set of login credentials.

An information that identifies resources that the client application is allowed to access.

Cookies that last for a session, that means they are stored in temporary memory locations and are removed after the session ends.

An authentication method that allows access to multiple resources after a single authentication flow with a single set of credentials.

A process in which an authorization server validates access token provided by a client. Information included in that token is used to determine whether the client is authorized to access the resource.

The SecureAuth CIAM platform user portal offers all the features that end users need to manage authorizations and consents that they grant to their applications.

The SecureAuth developer portal offers all the features that a developer needs to manage applications easily and securely with SecureAuth.

Workspace is the main administration interface of SecureAuth, that consists of an Authorization Server, integrated sources of identities, connected Applications and Authorizers (being an access control enforcement point and integration point for API gateways and Service Meshes). You can create multiple Workspaces in a tenant in order to support different use-cases (for example, meeting the Open Banking requirements or Partners B2B integration).