Home » Security Bloggers Network » What’s OpenID Connect (OIDC) and Why Should You Care?

What’s OpenID Connect (OIDC) and Why Should You Care?

by SSOJet - Enterprise SSO & Identity Solutions on June 19, 2025

Alright, let’s be honest — login systems are everywhere. From your favourite pizza delivery app to your office tools, every app asks you to Sign in with Google or Log in with Microsoft. Ever wondered how that works under the hood? That’s where OpenID Connect (OIDC) comes into play. In simple terms, OIDC is a modern way for apps to authenticate users by piggy backing on OAuth 2.0 (which you might already know powers those Sign in with… buttons). While OAuth is all about granting access to stuff like calendars and photos, OIDC adds an identity layer on top. This means it can also confirm who you are, not just whether you have permission to do something. Let’s take SSOJet — the product we’re building — as an example. Our goal is to help businesses connect their apps with multiple identity providers (like Google, Azure AD, Okta, and more) using standards like SAML and OIDC. If a customer wants users to log in with their Google account or Azure AD account, we plug into those providers using OIDC behind the scenes. Why should you care? Because OIDC makes logins faster, safer, and easier for both developers and users. No one wants to remember another password, and you don’t want to store passwords you don’t have to. With OIDC, you can offload that to trusted providers while still knowing exactly who’s using your app. In a nutshell:
<ul>
<li>OAuth 2.0 = "Can this app access my stuff?"</li>
<li>OpenID Connect = "Who’s the person behind this login?"</li>
</ul>
And the best part? They work together beautifully. In the next section, I’ll break down how this login flow actually works — with a simple, clean diagram to make sense of it all.
<h2>How the OIDC Login Flow Actually Works</h2>
Okay, so now you know what OIDC is. But how does it actually work when you hit that Login with Google button? Let’s break it down in plain English — no jargon, no fluff. Here’s the idea: your app (called the Relying Party in OIDC land, but let’s just call it your app) doesn’t want to deal with passwords. So, it hands that job over to a trusted Identity Provider (IdP) like Google, Microsoft, or whoever you choose. They’ll handle the login, and then tell your app who just signed in. Here’s a super simple version of the flow we use at SSOJet:
<h3>The OIDC Login Flow in 6 Quick Steps:</h3>
<ol>
<li>User clicks "Login with Google" on your app.</li>
<li>Your app redirects them to the Google login page with a special request (this includes things like your app’s client ID, what info you want, and where to send them after).</li>
<li>Users logs into Google (or maybe they’re already logged in).</li>
<li>Google asks, “Hey, is it cool if this app accesses your basic info?” The user clicks Allow.</li>
<li>Google sends a code back to your app through a redirect.</li>
<li>Your app takes that code and makes a secure call to Google’s /token endpoint to swap it for tokens — an ID Token (which says who logged in) and an Access Token (if you need to grab extra stuff like calendar events).</li>
</ol>
That’s it. User’s logged in.
<img src="https://cdn.pseo.one/6853a4a8a2796a91bb994a76/687e6d61f6fe799d28851eff/whats-openid-connect-oidc-and-why-should-you-care/oidc-flow-9834feef.webp" alt="">
<h3>Key Endpoints You’ll Use:</h3>
<ul>
<li><code>/authorize</code> — sends users to the login page</li>
<li><code>/token</code> — exchanges the code for tokens</li>
<li><code>/userinfo</code> — (optional) grab extra user profile info</li>
</ul>
At SSOJet, we use this exact flow whether our customer picks Google, Microsoft, or another OIDC-compliant provider. The nice part? OIDC standardizes this stuff, so you don’t have to build a new flow for every IdP.
<h2>Picking the Right Identity Provider (IdP)</h2>
Alright, now that we know how the OIDC login flow works, here’s the next thing you’ll need to figure out: which identity provider should your app use? If you're building for yourself, it’s simple — maybe you just need Google or Microsoft. But if you're building something like SSOJet, where your customers might use different providers (Google, Azure AD, Okta, etc.), you need to be a bit smarter about it. What’s an Identity Provider (IdP) Again? An IdP is basically the service that handles your users' authentication. It's the one saying, "Yep, this person is who they claim to be." How We Pick at SSOJet At SSOJet, our goal is to support whatever IdP our customers use. That’s why we made sure our system can plug into popular ones like:
<ul>
<li>Google Workspace</li>
<li>Okta</li>
<li>Microsoft Entra (Azure AD)</li>
<li>OneLogin and literally any IdP that talks OIDC.</li>
</ul>
<h2>OIDC Login Example — Let’s Build It in a .NET Web App</h2>
Alright — enough theory, let’s build something real. I’m going to show you how we set up a basic OIDC login in a .NET web app, similar to how we wired it up for SSOJet in our early prototypes. Good news: thanks to OIDC libraries and middleware, you don’t have to start from scratch.
<h3>What You’ll Need:</h3>
<ul>
<li>A .NET 6 or 7 Web App</li>
<li>An OIDC provider account (Google, SSOJet, Azure AD — pick your favorite)</li>
<li>A Client ID and Client Secret from your IdP</li>
<li>Redirect URI (like <code>https://localhost:5001/signin-oidc</code> for local testing)</li>
</ul>
<h3>Step 1: Configure Your Application</h3>
Go into your IdP’s developer console and create a new app/client:
<ul>
<li>Set Redirect URI (where the IdP will send the user after login)</li>
<li>Note down the Client ID and Client Secret</li>
<li>Choose the scopes you need (<code>openid</code>, <code>profile</code>, <code>email</code>)</li>
</ul>
In SSOJet, follow <a href="https://docs.ssojet.com/en/how-to-guides/sso/oidc-sso-connection/">this Guide</a> for configurning Application
<h3>Step 2: Add NuGet Packages</h3>
In your .NET project, grab the required package:
<pre><code>dotnet add package Microsoft.AspNetCore.Authentication.OpenIdConnect
</code></pre>
<h3>Step 3: Update Program.cs / Startup.cs</h3>
Here’s a simple config using SSOJet as an example:
<pre><code>builder.Services.AddAuthentication(options => { options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme; options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme; }) .AddCookie() .AddOpenIdConnect("oidc", options => { options.Authority = "https://aauth.ssojet.com/v1"; options.ClientId = ""; options.ClientSecret = ""; options.CallbackPath = "/signin-oidc"; options.ResponseType = "code"; options.SaveTokens = true; options.Scope.Add("openid"); options.Scope.Add("profile"); options.Scope.Add("email"); options.TokenValidationParameters = new TokenValidationParameters { NameClaimType = "name", RoleClaimType = "role" }; });
</code></pre>
Breakdown:
<ul>
<li>We’re telling .NET to use cookies for sessions</li>
<li>OIDC config points to the IdP (Google’s endpoint here)</li>
<li>It asks for tokens using the <code>code</code> flow (the safest one)</li>
<li>And we save tokens for later use (if needed)</li>
</ul>
<h3>Step 4: Add Login and Logout Endpoints</h3>
<pre><code>app.MapGet("/login", async context => { await context.ChallengeAsync(OpenIdConnectDefaults.AuthenticationScheme, new AuthenticationProperties { RedirectUri = "/" }); }); app.MapGet("/logout", async context => { await context.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme); await context.SignOutAsync(OpenIdConnectDefaults.AuthenticationScheme); });
</code></pre>
<h3>That’s It — You’re Live</h3>
Run your app, visit <code>/login</code>, and you’ll get redirected to Google’s sign-in page. Log in, and your app now knows who you are — using OIDC. In SSOJet, we built this same flow, but made it dynamic based on the customer’s chosen IdP config. So every client could plug in their Google or Microsoft tenant details and go live in minutes.
<h2>Meet the Tokens You’ll See in OIDC</h2>
When the IdP sends your app a response after a successful login, you’ll typically get:
<ul>
<li>ID Token → This is the important one for OIDC. It’s a JSON Web Token (JWT) that says who logged in.</li>
<li>Access Token → If your app needs to grab stuff from the IdP’s APIs (like profile info), you’ll use this.</li>
<li>Refresh Token (optional) → Lets you get new tokens later without asking the user to log in again.</li>
</ul>
In SSOJet, we mostly care about the ID Token for authentication. If the customer
<h3>What’s Inside an ID Token?</h3>
It’s a JWT — meaning it’s a Base64‑encoded JSON blob. Here’s an example decoded:wants extra profile data, we’ll hit the /userinfo endpoint using the Access Token.
<pre><code>{ "iss": "https://auth.ssojet.com/v1", "sub": "110169484474386276334", "aud": "123-client-id", "exp": 1713541225, "iat": 1713537625, "email": "[email protected]", "name": "John Doe" }
</code></pre>
Key parts to check:
<ul>
<li><code>iss</code> (issuer) — who issued this token</li>
<li><code>aud</code> (audience) — should match your app’s client ID</li>
<li><code>exp</code> (expiry) — when the token stops being valid</li>
<li><code>sub</code> — the unique ID for this user</li>
</ul>
<h3>How to Validate Tokens (and Why You Should)</h3>
Don’t just accept any token you get. Validate it. Here’s what we check at SSOJet before trusting any ID Token:
<ul>
<li>Verify the signature — Make sure it’s signed by the right IdP</li>
<li>Check the issuer (<code>iss</code>) — Should be your IdP’s URL</li>
<li>Check the audience (<code>aud</code>) — Must match your app’s client ID</li>
<li>Check the expiry (<code>exp</code>) — Don’t accept old tokens</li>
<li>Confirm the nonce (if used) — Protects against replay attacks</li>
</ul>
You can easily validate JWTs using libraries like <code>System.IdentityModel.Tokens.Jwt</code> in .NET, or decode them on <a href="https://jwt.compile7.org/">jw</a><a href="https://jwt.compile7.org/">t.compile7.org</a> to peek inside.
<h3>Where Should You Store Tokens?</h3>
Here’s the rule we follow at SSOJet:
<ul>
<li>ID Tokens and Access Tokens → Store in secure, HTTP-only cookies or server-side session stores.</li>
<li>Never store them in localStorage or sessionStorage in the browser — those get snatched easily by cross-site scripting (XSS) attacks.</li>
</ul>
And if you’re keeping Refresh Tokens (which we usually avoid in SPAs or public clients), keep them server-side only.
<h3>Handling Token Expiry</h3>
Tokens don’t live forever — and that’s a good thing. When an Access Token or ID Token expires:
<ul>
<li>Either redirect the user to log in again</li>
<li>Or if you’ve stored a Refresh Token (on the server), swap it for new tokens silently</li>
</ul>
At SSOJet, for security, we usually avoid long-lived Refresh Tokens for public-facing apps and opt for short sessions with easy reauthentication flows.
<h2>That’s a Wrap</h2>
So there you go — from what OIDC is, how its login flow works, how to pick your IdP, wire it up in a .NET app, handle tokens safely, to managing sessions and logouts like a pro. This is exactly how we built the authentication flow at SSOJet, and it’s been rock solid for customers big and small. Next move? Spin up your own test project, plug in Google as an IdP, and watch the magic happen. Once you get the basics down, you’ll be ready to connect Azure AD, Auth0, or any other OIDC-compliant provider you want. If you liked this breakdown, drop a comment — or check out our other posts on SAML, magic links, and passkeys. Always happy to nerd out on auth stuff.

*** This is a Security Bloggers Network syndicated blog from SSOJet - Enterprise SSO & Identity Solutions authored by SSOJet - Enterprise SSO & Identity Solutions. Read the original post at: https://ssojet.com/blog/whats-openid-connect-oidc-and-why-should-you-care

June 19, 2025June 19, 2025 SSOJet - Enterprise SSO & Identity Solutions

What’s OpenID Connect (OIDC) and Why Should You Care?

Senator Sanders Wants to Own AI Companies — and Hand America’s Adversaries the Keys

NIST’s Nine: The PQC Signature Race Moves to Round Three

The Quantum Arms Race: Why Washington Just Wrote a $2 Billion Check to Nine Companies

Beyond Moore’s Law: The Hyper-Acceleration of Autonomous AI Cyber Capabilities

The Exception Economy: When Security Teams Stop Protecting and Start Negotiating

GoPlus’s Latest Report Highlights How Blockchain Communities Are Leveraging Critical API Security Data To Mitigate Web3 Threats

C2A Security’s EVSec Risk Management and Automation Platform Gains Traction in Automotive Industry as Companies Seek to Efficiently Meet Regulatory Requirements

Zama Raises $73M in Series A Lead by Multicoin Capital and Protocol Labs to Commercialize Fully Homomorphic Encryption

RSM US Deploys Stellar Cyber Open XDR Platform to Secure Clients

ThreatHunter.ai Halts Hundreds of Attacks in the past 48 hours: Combating Ransomware and Nation-State Cyber Threats Head-On

Fortinet® Follies