Authentication and Authorization Basics

Authentication and authorization play an important role in most application suites. This page provides a general overview of the concepts and terminology. It will be helpful if you're new to the subject or if you'd like a refresher. If you're confident in your general understanding, you can move on to learning how authentication and authorization work in CXone.

When users log in to any application suite, including CXone, these two steps typically occur in the order shown:

• Authentication—Is the user who they claim to be?
• Authorization—Should the authenticated user have the access they've requested?

All users must be authenticated and authorized before they can access CXone.

From the user's standpoint, they're simply logging in. Authentication and authorization happen behind the scenes to make their login successful. At the beginning of a login, users are unauthenticated. This means the system doesn't know their identity. At the end of the login, they're both authenticated and authorized. This means the system knows who they are and what access they should have.

A system does the following to authenticate and authorize users:

1. Determines what authentication process to use if more than one is supported. Many systems support multiple methods. For example, systems can identify users with a username and password, through single sign-on, or through multi-factor authentication (MFA). Generally, users choose from a list of authentication options on the login page, but systems can require a specific process when necessary.

2. Gathers authentication credentials (for example, by asking users for their username and password).

3. Verifies credentials using an identity provider. An identity provider is a separate system that maintains information about users and their identity, including their credentials.

4. Authorizes the authenticated individual or program. Once users are authenticated, the system uses an authorization server to grant access to the user. The system grants access to the user based on their role and permissions. The system only grants the user access to the features that they have permission to see or use.

Authentication-Related Terminology

Identity Provider

Identity providers (IdPs) are systems that establish a user's identity. They can be:

• Internal—Part of the system the user logs in to. For example, a user logging in to Facebook uses the Facebook IdP to authenticate to the Facebook application.
• External—Separate from the system the user logs in to. For example, a user logs in to a smartphone app using Facebook IdP authentication.

IdPs can be either hosted or cloud-based. Microsoft ADFS and Shibboleth are common hosted IdPs. Microsoft Azure AD, Okta, and Ping are among the many cloud IdPs.

Authentication Protocols

Authentication protocols establish communication between applications and IdPs, or between different IdPs. OpenID Connect and SAML 2.0 are examples of authentication protocols. Some authentication protocols offer additional features, such as encryption, but applications may or may not use these features. When a system uses a built-in IdP, authentication protocols are not a consideration.

Authentication Flow

Most external IdPs support one or both of the following flows for the authentication process:

• SP-initiated: Authentication is initiated by the service provider, or application. The user enters credentials and the application contacts an external IdP for identity verification. This is the most common flow.
• IdP-initiated: Users log in to the IdP first, and then the IdP launches applications after it verifies the user.

Federated Identity Management

Federated Identity Management is sometimes called FIM or federation. It is an umbrella term for the process of using a single external IdP to provide authentication for one or more applications. Federation is generally time-limited in some way. For example, a user may log in once when they start work. This authenticates them to all the applications they use each day. However, they would have to log in again the next day to reauthenticate, even if they didn't log out the day before.

Single Sign-On

Single sign-on (SSO) is used to provide access to multiple applications or systems based on one login. For example, a user logs in to Microsoft 365 and gains access to all the Microsoft applications their company has authorized for them. Sometimes the term SSO is used for federation, although the two concepts are not exactly the same.

Multi-factor Authentication

Multi-factor Authentication (MFA) adds another level of security to basic username/password authentication. MFA requires the user to enter a code, answer a question, or use a token before the IdP considers their identity verified.

Trust

In authentication, trust refers to information or knowledge shared by an application or system and an external IdP. This knowledge establishes a relationship between the two so that each knows it can rely on accurate and truthful communication from the other. How trust is established differs depending on the authentication protocol. The following examples are based on OpenID Connect and SAML 2.0.

OpenID Connect

Trust in OpenID Connect is based on the issuer. An issuer is a value that looks like a URL. It establishes your identity provider. For example, Google supports OpenID Connect and the issuer is https://accounts.google.com.

Based on the issuer, there are several additional configuration items. For example, in OpenID Connect trust is established through public/private certificate signing. It uses an industry-standard called JWKS. Therefore, part of the configuration determines how these public certificates are obtained.

Most identity providers support the discovery of this information by appending /.well-known/openid-configuration to the issuer. The Google discovery document is at https://accounts.google.com/.well-known/openid-configuration.

SAML 2.0

In SAML 2.0, trust is based on an entity identifier. Unlike OpenID Connect, there isn't a strong relationship between the entity identifier and other configuration values. There are several configuration parameters used to establish trust with SAML 2.0:

• Entity identifier—Value established by the application or system to verify its identity

• Endpoint URL—Value determined by the external IdP at which it receives authentication requests

• Assertion URL—Value determined by the application or system to which the external IdP sends authentication responses

• Certificate—Used by the external IdP to sign the response