Authentication design considerations

Understanding the authentication methods in Pega Platform is essential for Lead System Architects who design secure and scalable authentication architectures. Each protocol supports specific use cases and deployment models.

SAML 2.0

Security Assertion Markup Language (SAML) 2.0 is an XML-based standard for exchanging authentication and authorization data between identity providers and service providers. In Pega Platform, SAML 2.0 enables SSO, allowing users to authenticate once and access multiple applications without reentering credentials.

SAML 2.0 relies on a trust relationship between three entities: the user (principal), the IdP, and the service provider (SP). In Pega implementations, Pega Platform functions as the service provider. External systems such as Microsoft Azure Active Directory, Okta, or on-premises ADFS serve as identity providers. When a user accesses a Pega application, the system redirects the user to the IdP for authentication. After successful authentication, the IdP returns a SAML assertion with user identity data and attributes. Pega Platform uses this assertion to authorize the user and establish a session.

OpenID Connect

OpenID Connect (OIDC) builds on OAuth 2.0 to support user authentication in web and mobile applications. Many developers choose OIDC over SAML 2.0 because OIDC offers simpler configuration, greater flexibility, and native support for mobile and single-page applications.

OIDC supports API authorization by using OAuth 2.0 scopes and access tokens. SAML focuses on authentication only. This difference makes OIDC a better fit for applications that require both user authentication and API access. OIDC also defines standardized endpoints and supports discovery through the OpenID Connect Discovery specification. Applications use this specification to dynamically locate IdP endpoints and features without manually configuring multiple URLs.

OAuth 2.0

OAuth 2.0 is an authorization framework that enables applications to obtain limited access to resources on behalf of a user or the application itself. While OIDC builds on OAuth 2.0 to support authentication, OAuth 2.0 focuses on authorization and determines what actions an authenticated entity can perform.

OAuth 2.0 includes several grant types, each designed for specific use cases and security contexts. The authorization code grant type offers the most secure option for server-side applications that can protect the client secret. In this flow, the resource owner (user) grants consent by signing in through the authorization server. After the user consents, the server returns an authorization code to the application. The application then sends a back-channel request that includes the client secret to exchange the code for an access token.

Use the authorization code grant type when your application needs to access resources on behalf of a specific user and can securely store client credentials. In Pega applications, this grant type supports access to external APIs on behalf of the logged-in user, such as retrieving documents from a cloud storage service or data from an external CRM system.

Use the client credentials grant type for server-to-server communication when the application acts on its own behalf. In this flow, the application authenticates with the authorization server by using its client credentials and receives an access token that represents the application's identity. This grant type is well-suited for batch processes, system integrations, and background jobs that do not require a user context.

Use the resource owner password credentials grant type only in highly trusted scenarios. This grant type requires the application to collect the user's credentials directly and exchange them for an access token. First-party applications might use this grant type when the application and the authorization server belong to the same organization and share a high level of trust. However, redirect-based flows are generally preferred because they do not expose passwords to the application.

Token credentials

Mobile applications introduce unique authentication challenges because of offline access, limited input methods, and security constraints. Token credentials authentication addresses these mobile-specific requirements while maintaining strong security.

Pega Mobile Client supports multiple authentication patterns. You can configure direct sign-in with Pega credentials (with multi-factor authentication), SSO through external IdPs using OIDC or SAML, and biometric authentication for secure token access. On first login, the system issues access and refresh tokens and stores them securely on the device. These tokens enable seamless reauthentication in future sessions. Biometric methods, such as fingerprint or face recognition, unlock stored tokens instead of serving as the primary authentication method.

Select the authentication type based on the following factors:

• Security needs: Consider the sensitivity of the data and the security policies of your organization.
• User convenience: Balance security with user experience, especially for customer-facing applications.
• Existing infrastructure: Use existing authentication systems (for example, LDAP, SSO) to streamline management.
• Integration requirements: Select methods that facilitate integration with other systems and services that you use.

Align the authentication type with your organization's security strategy and operational requirements.

Check your knowledge with the following interaction: