These three standards manage similar concepts with different names. The following table describes common concepts to all SSO standards:

Both SAML and OIDC standards address the same concerns about access control to enterprise services, public services or mixed services. Both SAML and OIDC define one or more processes to delegate authorization (OAuth2), or authentication and authorization (OIDC and SAML) to one or more third-party identity providers.

The SAML standard was established earlier than OAuth2 and OIDC, in 2005. Thus, SAML is widely present in enterprise environments, and there are an elevated number of homemade applications, and software products that support out-of-the-box integration with a SAML identity provider.

However, OIDC finalized its definition more recently, in 2014. OIDC is natively designed for working with web architectures, and with different devices, such as smartphones, or smart televisions. SAML has an issue with single-page applications (SPA), or native applications, running in devices with limited user interfaces or limited computing power: SAML needs the private key to sign each request to the SAML IdP. If somebody compromises the device, then the attacker can impersonate the user to perform HTTP requests by signing in with that key.

OIDC is lighter than SAML, because the JSON format of requests and responses defines much smaller messages between the parties of the SSO system.

OAuth2, and therefore OIDC, make it easier to federate more than one identity provider in the same RH-SSO realm.

Furthermore, SAML has a higher learning curve than OAuth2 and OIDC because its flows and profiles are more complex than OIDC.

Unless you have previously existing SAML applications, Red Hat recommends you choose OIDC over SAML for your SSO architectures.

OIDC uses a family of standards called JavaScript Object Signing and Encryption (JOSE). The main standard in JOSE is JSON Web Token (JWT, RFC 7519). The JWT token is a standard format for representing information in a non-opaque piece of text data. Some of JWT advantages are the following:

Each standard defines a collection of endpoints in the identity server. These endpoints let you send a request to the identity server to start different processes or flows related to authentication and authorization. The OIDC standard, added endpoints for self-registration of new clients and users, an endpoint for requesting user info, and endpoints for discovering the configuration of the identity provider.

The authentication and authorization flows define the processes used to obtain the tokens when the user is authenticated. OAuth2 define many authorization flows, known as grants. OIDC defines other different flows, that use and extend the OAuth2 grants. Each flow defines which requests and parameters your developers need to use in every step of the authentication or authorization process, by using the web endpoints of the OIDC standard.

In RH-SSO, you configure which flows you allow in each client configuration within the Admin Console, from Configure → Clients, in the Settings tab.

In addition to the flows, each client can be of three types:

From the application perspective, the developer chooses the flow and client type, by configuring the OIDC library, or RH-SSO adapter, that the application uses.

This lecture describes only the recommended flows, and the flows that you must use depending on the type of client or application. To learn more about all the OIDC flows supported by RH-SSO, refer to the OIDC auth flows section of the Server Configuration Guide at https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.6/html-single/server_administration_guide/index#con-oidc-auth-flows_server_administration_guide

The recommended default flow is the OIDC Authorization Code Flow with confidential clients. The following diagram is an UML sequence diagram depicting the flow:

The hybrid flow is different from the authorization code flow in the step that returns the temporary code. The hybrid flow returns also the ID token in this step.

The client credentials flow, or more specifically the client credentials grant from OAuth2, is called Service Account in RH-SSO. It is used when the application client accesses the protected resource on behalf of itself.

The device flow, or more specifically the device authorization grant from OAuth2, is targeted to devices with very limited user interface, such as televisions, or embedded systems. It uses a device code, a user code, and a verification URL pointing to the identity server. The device flow uses a secondary browser on the same device, or in a different device.

The traditional web applications use the authorization code flow to obtain an ID token. Then, the applications create an authenticated HTTP session by using that ID token.

Use the authorization code flow with confidential type clients.

The flow on an SPA depends on the architecture of the application.

If the SPA makes requests to a dedicated API in the same domain name, then it can be treated as a regular server side web application.

If the SPA makes requests to an API in a different domain, then the recommended architecture is to implement an intermediary API to call the external API. If the SPA makes direct requests to the external API, then you can use the authorization code flow with a public client. Thus, the user browser receives the tokens that represent a security risk. To mitigate this risk, Red Hat recommends you use the authorization code flow with public client, plus the Proof Key for Code Exchange (PKCE) extension to the OAuth2 standards. PKCE associates the temporary authorization code with a second verification code, which is stored in the user browser, or device. If somebody stole the temporary code, then the attacker can not use it because only the user browser has the second code.

This type can include services that use gRPC, or WebSockets. REST APIs and services receive requests only with the access or bearer token. In a microservices architecture your developers need to propagate the access token between services invocation.

Figure 3.3: Requests to services propagating the access token.

Use the authorization code flow with bearer-only type clients, unless you need the service acting on behalf of itself. Then, use the client credentials grant, called service account in RH-SSO.