Signing into a digital resource, like a website or app, is a regular part of modern life. But behind that seemingly simple action is a detailed process that’s taken many years and — input from many people and companies — to develop. Identity management, including sign-in, is underpinned by a series of protocols. These protocols handle the online transactions between people and systems. One of the most common identity protocols is OpenID Connect (OIDC), which can be used to implement single sign-on (SSO).

Here, AccessOwl looks at the use of OIDC with SSO and the implementation of best practices.

What is OIDC (OpenID Connect)?

OpenID Connect, or OIDC, is an identity authentication protocol developed by the OpenID Foundation. It handles the verification of a user's identity when they attempt to access a resource, like an app. OIDC also facilitates the sharing of user claims, like name, email address, etc. It’s a standard built upon OAuth 2.0 and uses the authorization mechanisms that are part of that protocol. 

Many types of apps and services use OIDC, including single-page web apps (SPA) and native and mobile apps. OIDC also handles single sign-on (SSO) across OIDC federated applications. 

What is SSO (single sign-on)?

Employees often sign in to multiple apps daily to do their jobs. Continually signing in and out can impact productivity and security, with employees reusing passwords to avoid password fatigue. Having the ability to sign on once to access multiple applications per session is known as single sign-on (SSO). With SSO, employees no longer need to memorize multiple passwords, so the user experience is enhanced and security improved.

Benefits of using OIDC for SSO

OIDC, when used to implement SSO, offers a company several essential benefits:

Simplifies authentication

When SSO is implemented using OIDC, a user simply has to login once to an OIDC provider to then access multiple services and apps, seamlessly.

Centralizes access control

SSO is a way to centralize access control management. Centralized access control provides better visibility and the ability to monitor access events, reducing provisioning errors and mitigating unauthorized access.

Improves security

OIDC handles transactions using tokens; ID and access tokens generated during login contain identity data. Tokens are digitally signed to prevent tampering and may be encrypted to provide additional security. These tokens establish the identity of a user without needing to share credentials directly with services and apps. This improves security by reducing credential exposure. SSO also eliminates the reuse of passwords for multiple app access.

Provides consent to share data

One innovative feature of OIDC that sets it apart from identity protocols like SAML is that consent to share data is built into the protocol. OIDC is often used in consumer-facing services, where data sharing requires consent for compliance with regulations like GDPR.

SSO implementation best practices

Any app or web service designer can integrate with an OpenID provider (OP), such as a social network like GoogleID. The app or service must present a UI, such as a button, allowing users to connect to their OP login. The following best practices when implementing SSO via OIDC should be considered:

Multi-factor authentication (MFA)

Single sign-on should be used with robust authentication measures, such as MFA. Examples of MFA measures include mobile app authenticator codes or biometrics.

Step-up or risk-based authentication

SSO can be augmented by applying security rules that trigger additional authentication requests. For example, users who log in from an unknown IP address may be required to submit additional authentication before being allowed SSO access to apps.

Real-time monitoring

SSO provides a centralized framework for identity and access management. This centralization also provides a way to monitor access events in real-time. Having the ability to monitor user activities provides a way to identify access anomalies and suspicious behavior. Governance platforms, like AccessOwl, provide shadow IT discovery that can sync with your SSO provider, ensuring that application usage can be continuously monitored.

Single logout

SSO sometimes comes with the option for single log-out (SLO). This can be more complicated to implement than single sign-on and often comes down to presenting logout options to users. For example, someone may log out of one app but wish to remain working in another. If SLO is a requirement, the user should be presented with a granular UI to allow them to decide which apps to log out from, with each app handling the logout separately.

Example of OIDC SSO

Google acts as an OIDC provider (OP) to facilitate OIDC SSO. Google Sign-In can be integrated into an app, with a Google Sign-In button added to the UI. When the user clicks the Google button, they’re redirected to the Google sign-in page. Once authenticated, they’re redirected back to the app, where they are automatically signed in. So any app integrating Google Sign-In allows users to sign in seamlessly.

OIDC vs. SAML for SSO

Both OIDC and SAML support SSO. However, they differ in how they’re implemented and the types of use cases supported.

OIDC was built to support more consumer-facing use cases and is designed for use with social federated logins like AppleID, Google Sign-In, and Facebook. OIDC is built upon OAuth 2 and handles modern requirements for consented data sharing. OIDC is also considered a “lightweight” protocol, as its architecture is based upon JSON web tokens (JWTs), which have reduced processing needs. OIDC is based on the modern architectural standards of JSON and RESTful APIs.

SAML is an older protocol developed before the advent of federated social logins. It’s often used in enterprises that must support legacy applications. SAML is based on a larger, more complex XML document schema. It was not designed for use with single-page applications (SPAs) and mobile apps.

Both SAML and OIDC can be implemented securely, but SAML is typically considered more secure than OIDC. Security, however, comes down to the implementation of the protocol rather than the protocol itself.

OIDC SSO and user provisioning and deprovisioning

User provisioning and deprovisioning is an important aspect of identity management. As employees join or leave a company, their access rights, including SSO rights, must be added or removed. Automation of identity provisioning and deprovisioning ensures that an employee's SSO access is removed when they leave, canceling access across all federated apps. This improves the company's overall security posture and compliance. Identity governance platforms like AccessOwl provide automation of identity provisioning and deprovisioning.

SSO and shadow IT

Employees may be tempted to sign up for apps using free or cheap trial subscriptions. Unsanctioned apps are a compliance, legal, and security nightmare. This problematic shadow IT creates security gaps, as the SaaS apps are unmanaged. Company data flows are then incorporated into these unvetted apps.

Shadow IT is a gray area in IT and requires mechanisms, like app discovery, to bring them under company control. Modern governance solutions, like AccessOwl, make shadow IT apps visible, creating a single source of truth. AccessOwl's shadow IT register collates all apps, including shadow IT apps. Apps can then be federated with an OIDC identity provider (OP) to facilitate SSO. Employees then benefit from a consolidated app login across all apps. Companies benefit from having surety that their access controls reflect the employee’s role and its own security policies.

SSO allows a company to centrally manage and simplify employee access to applications. Implementing SSO using OIDC offers benefits such as improved security and productivity. A governance layer should be used alongside your SSO efforts. Combined with SSO, this will provide visibility across all apps and can be used to perform access reviews to augment and enhance SSO.