Access Token

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 Cloudentity we always refer to the OAuth 2.0 Access Tokens. Access tokens are issued by an authorization server, such as Cloudentity, 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.

Application (Client and Service)

In Cloudentity, 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 Cloudentity Workspace constitutes the OAuth 2.0 Resource Server.

Learn more about apps in Aplications Overview.

Authentication

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.

Authorization

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

Authorization flow

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.

Authorizer

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 Cloudentity 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 Cloudentity 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 Cloudentity 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 with Cloudentity.

Authorization Server

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. Cloudentity’s administrator portal allows for the configuration of authorization server capabilities, including grant types management, token settings, client registration, and client authentication. Cloudentity allows to create multiple authorization servers per tenant.

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

Brute-Force Protection

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, Cloudentity can block an account that exceeds the defined request threshold. You can learn more in Brute Force Protection documentation.

BYOID

Bring Your Own Identity (BYOID) is a philosophy that Cloudentity strongly believes in. Cloudentity 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, Cloudentity 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 Cloudentity , 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 Cloudentity with an external datastore. It requires more work on your side, but allows you to bring Cloudentity with its advanced authorization and governance capabilities into your system to make sure your applications and APIs are secure.

Claim

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.

Consent

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.

Extension Scripts

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

Fine-Grained Access Control

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.

ID Token

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 (IDP)

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 Pools

Identity Pool allows for the persistent storage of user data within Cloudentity’s infrastructure, thus providing the alternative to the Bring Your Own Identity (BYOID) approach typically used by Cloudentity 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 Cloudentity (or register in the Identity Pool first).

Identity Schema

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 in Configuring Identity Pools.

Passwordless Authentication

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:

• There is no password so you can’t give it away to a phishing site
• Your credentials are never stored on the server, in fact, they never leave the device used for authentication

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

When authenticating with Cloudentity 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)

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).

Multi-Factor Authentication (MFA)

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.

Open Authorization (OAuth 2.0)

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

OpenID Connect (OIDC)

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 (Proof Key for Code Exchange)

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.

Policy

Cloudentity Policies provide the multilevel authorization as the response to modern access control requirements. Cloudentity 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:

1. Workspace level

   All requests that happen in the context of the workspace have this policy evaluated first. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, Cloudentity responds with the 403 error to a token request.

2. Application level

   If a policy is assigned to a client application that requests a token, the policy is evaluated as a part of the OAuth authorization and authentication process. To learn more this process, see OAuth documentation. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, Cloudentity responds with the 403 error to a token request.

3. OAuth scope / service level

   If an application requests a specific scope with a policy assigned to it, the policy is evaluated. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, Cloudentity still returns a token to the application, but the token does not include the scopes for which the policy evaluation ends with a failure.

4. API layer level

   API layer is evaluated if you use the authorizers as an API enforcement layer. API policies evaluate the context of the request and context of the client or the user that is included in the access token. If the policy passes, the authorizer allows this API request. If it fails, the API request is blocked. If you are using Istio Authorizer, you can add a layer of policy orchestration using the native Istio policy and describe the conditions under which the Cloudentity authorization needs to be evaluated.

   

Role-based Access Control (RBAC)

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 Token

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.

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.

Security Assertion Markup Language (SAML)

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.

Scope

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

Session Cookie

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

Single Sign-on (SSO)

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

Token introspection

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.

User portal

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

• If you do have authorized applications, the Cloudentity user portal shows them listed as Third-party applications with account access.

  

• If you have not authorized any applications to access your account, the Cloudentity user portal displays message You haven’t granted consents to any applications yet.

  

Developer portal

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

• If you already have applications in Cloudentity, the Cloudentity developer portal opens with the preview of your applications and enables you to configure their settings and access details (1). You can also add more applications with CREATE APPLICATION (2).

  

• If you have no applications created in Cloudentity so far, the Cloudentity developer portal opens with CREATE APPLICATION, which invites you to build your new applications.

  

Workspace

Workspace is the main administration interface of Cloudentity, 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).