What is OIDC?

OpenID Connect (OIDC) is a simple way for apps and websites to let users log in using an existing account from another service (like Google or Facebook). It builds on the OAuth 2.0 protocol and adds a standard “identity layer” that tells the app who the user is.

Let's break it down

  • OpenID Connect (OIDC): a set of rules that lets one system (the “relying party”) ask another system (the “identity provider”) to confirm a user’s identity.
  • Identity Provider (IdP): the service that already knows the user (e.g., Google, Microsoft). It checks the password and creates a proof that the user is who they claim to be.
  • Relying Party (RP): the app or website that wants to let the user log in without creating a new password.
  • OAuth 2.0: the underlying “permission” protocol that lets the RP get limited access to the IdP’s data. OIDC adds the “who-are-you” part on top of this.
  • ID Token: a small, signed piece of data (usually a JWT) that the IdP sends back to the RP, containing the user’s name, email, and a unique ID.
  • Access Token: a token that can be used to call other APIs; not the main focus of OIDC but often returned together.

Why does it matter?

It saves users from remembering many passwords and reduces the work for developers who would otherwise have to build their own login system. By using a trusted IdP, security is higher and the risk of password-related breaches drops.

Where is it used?

  • Social login on e-commerce sites (e.g., “Sign in with Google”).
  • Enterprise single sign-on (SSO) for cloud services like Microsoft Azure AD or Okta.
  • Mobile apps that let users authenticate via Apple ID or Facebook.
  • API gateways that need to verify a user’s identity before granting access.

Good things about it

  • Standardized: widely adopted specifications mean many libraries and tools already exist.
  • Built on OAuth 2.0: leverages an already-trusted, battle-tested protocol.
  • User convenience: reduces password fatigue and speeds up sign-up.
  • Improved security: passwords stay with the IdP, lowering exposure for the RP.
  • Scalable: works for both small websites and large enterprise ecosystems.

Not-so-good things

  • Implementation complexity: setting up the flow correctly can be tricky for beginners.
  • Dependency on third-party IdPs: if the IdP experiences downtime, users can’t log in.
  • Token management: developers must handle token validation, expiration, and revocation securely.
  • Privacy concerns: sharing user data with an external IdP may raise compliance or user-trust issues.