OIDC, or OpenID Connect, is an authentication protocol layered on OAuth 2.0. It lets an application send a user to an identity provider to log in and get back a signed ID token, a JWT that states who the user is, which provider verified them and when. It powers social logins and much of modern single sign-on.

What is the difference between OIDC and OAuth 2.0?

OAuth 2.0 is about authorisation: granting an application limited access to a resource on the user's behalf, without revealing who the user is in a standard way. OIDC adds authentication on top by defining the ID token, the openid scope, discovery and the UserInfo endpoint, so the application can reliably know the user's identity.

What is the difference between OIDC and SAML?

Both provide single sign-on through an identity provider. SAML is an older XML-based standard designed around browser redirects and is entrenched in large enterprises. OIDC is JSON and REST based, easier to implement, and suits mobile apps and APIs. Most enterprise identity providers support both; newer platforms usually implement OIDC first.

Is an OIDC ID token the same as an access token?

No. The ID token is a JWT meant for the application, proving who the user is and how they logged in. The access token is meant for the resource server or API and grants access to it; it may be a JWT or an opaque string. Applications should not use the ID token to call APIs or the access token to establish identity.

Does Ethora support OIDC login?

Ethora's social sign-on uses OAuth and OIDC providers such as Google, Apple and Facebook, and dedicated deployments can delegate authentication to the customer's enterprise identity provider. Alternatively, API-provisioned end users let your own backend, having authenticated the user however you choose, create the chat user and token so no separate Ethora login appears.

Glossary

OIDC (OpenID Connect)

The protocol behind “Sign in with Google” and most modern single sign-on. OIDC adds an identity layer to OAuth 2.0 so an app learns who the user is, not just what it may access on their behalf.

General definition

OIDC (OpenID Connect) is a thin identity layer standardised by the OpenID Foundation in 2014 on top of the OAuth 2.0 authorisation framework. OAuth 2.0 on its own answers “may this app access this resource?” and says nothing reliable about who the user is. OIDC fixes that by defining an ID token, a signed JWT issued by the identity provider (the OpenID Provider) to the application (the Relying Party) with claims such as iss (issuer), sub (a stable user identifier), aud (the intended app), exp and nonce, plus optional profile claims like name and email.

Authorization code flow with PKCE: the recommended flow for web, mobile and single-page apps; the browser is redirected to the provider, the app exchanges a one-time code for tokens over a back channel
Discovery: the provider publishes its endpoints and signing keys at /.well-known/openid-configuration, so clients configure themselves
UserInfo endpoint: returns additional claims about the authenticated user when the app presents an access token
Scopes: openid switches OIDC on; profile, email and others request particular claims
Logout: optional specifications cover front-channel, back-channel and RP-initiated logout

The usual comparison is with SAML, the older XML-based enterprise standard. Both deliver single sign-on from a central identity provider. SAML is browser-centred, verbose and deeply embedded in large enterprise IdPs; OIDC uses JSON and REST, fits mobile apps and APIs naturally, and is what consumer providers (Google, Apple, Microsoft) and newer workforce IdPs lead with. Most enterprise IdPs support both, and buyers in regulated sectors increasingly accept either as long as the application delegates authentication to the corporate directory and honours deprovisioning.

Two things OIDC does not do. It does not by itself provision or remove user accounts in the application; that is left to just-in-time creation at first login or to a provisioning protocol such as SCIM. And it does not define what the user may do inside the application; roles and permissions remain the application’s job, informed by claims or group memberships the provider chooses to share.

In the Ethora ecosystem

Ethora’s social sign-on options (Google, Apple, Facebook and others) are OAuth and OIDC integrations: the user authenticates with the provider, Ethora receives the identity claims and issues its own short-lived JWT chat tokens for the session. On dedicated deployments the same delegation pattern can extend to enterprise SSO against the customer’s identity provider, so staff use their corporate login and access is revoked centrally when they leave.

Many customers avoid a visible Ethora login altogether. With API-provisioned end users, the customer’s own backend, which already authenticated the person through OIDC, SAML or anything else, creates the chat user and obtains a chat token for them, so the messaging inside a patient portal or banking app inherits whatever identity system the host application trusts. Roles inside Ethora are then set through the admin panel and API rather than inferred from the provider.

Chat and AI built for regulated industries

Ethora gives you audit trails, retention controls, a Trust & Safety layer and dedicated deployments in your own cloud. Talk to our team.

Free tier available Enterprise SLA No vendor lock-in