What is OpenID Connect and why does it matter?
If you have ever been asked “What is OpenID Connect” in a technical interview, you know it is easy to get lost in the alphabet soup of OAuth and JWTs. Put simply, What is OpenID Connect (OIDC) is an identity layer that sits right on top of the OAuth 2.0 framework. It allows your application to verify who a user is based on the authentication performed by an Authorization Server.
In my experience, teams often struggle to separate “who you are” from “what you can do.” OIDC handles the “who” part. It standardizes how we sign users in and get their profile data. Instead of building a custom login system for every app, we can use a single, secure method to connect with providers like Okta, Azure AD, or even Salesforce.
But why should you care? Because OIDC solves the headache of federated sign-in. It uses standard REST/JSON and JWT-based protocols, which means it works the same way whether you are building a mobile app or a complex Salesforce API integration. It is all about interoperability.
The core concepts you need to know
- Identity Provider (IdP): This is the server that handles the login and issues the tokens. Think of Salesforce or Google.
- Relying Party (RP): This is your application. It relies on the IdP to tell it who the user is.
- ID Token: A JSON Web Token (JWT) that contains the user’s identity details.
- Access Token: This is for authorization. It lets you call protected APIs.
- Refresh Token: A long-lived token used to get new access tokens without making the user log in again.
Understanding What is OpenID Connect vs OAuth 2.0
This is the part that usually trips people up. Look, OAuth 2.0 is strictly about authorization. It is like a valet key for a car – it lets someone drive the car, but it doesn’t tell them who the owner is. OIDC adds that identity layer on top. It provides a standardized ID token and discovery metadata so your app knows exactly where to look for user info.
I have seen plenty of developers try to use the Salesforce JWT flow or other OAuth flows to handle identity without OIDC, and it usually ends with them writing a bunch of extra code to fetch user profiles. OIDC gives you that “UserInfo” endpoint out of the box. It makes life much easier.
Practical Tip: Never use an Access Token to identify a user. Access tokens are opaque to the client and meant for the API. Always use the ID Token for identity verification.
How What is OpenID Connect actually works
When you implement OIDC, there are a few key endpoints you will interact with. The Authorization Endpoint is where the user actually types in their password. Once they are authenticated, the Token Endpoint is where you exchange a code for your tokens. Most importantly, the Discovery Endpoint (usually found at .well-known/openid-configuration) tells your app everything it needs to know about the provider’s setup.
Now, let’s look at the ID Token itself. It is a JWT with three parts: a header, a payload, and a signature. The payload contains “claims,” which are just pieces of info about the user. Here is what a typical decoded payload looks like:
{
"iss": "https://idp.example.com",
"sub": "248289761001",
"aud": "your-client-id",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"email": "[email protected]"
}Common authentication flows
So which flow should you use? For most modern web apps and SPAs, the Authorization Code Flow with PKCE is the gold standard. It is way more secure than the old Implicit Flow, which I honestly wouldn’t recommend for any new project. If you are doing machine-to-machine work, you might see Client Credentials, but remember that OIDC is specifically for when a human user is involved.
Best practices and security
Security isn’t something you can just “set and forget.” When you are working with OIDC, you have to validate that ID token every single time. Check the issuer (iss) to make sure it came from your trusted IdP, check the audience (aud) to ensure it was meant for your app, and always verify the signature.
And here is another thing: always use HTTPS. It sounds obvious, but you would be surprised how many times I have seen metadata or keys fetched over insecure connections during development. If you are preparing for Salesforce developer interview questions, being able to explain why we use PKCE for public clients will really set you apart.
Key Takeaways
- OIDC is an identity layer built on top of OAuth 2.0.
- The ID Token is the “source of truth” for who the user is.
- The Discovery Endpoint makes it easy to configure your app automatically.
- Always prefer the Authorization Code Flow with PKCE for security.
- OIDC standardizes scopes like “openid”, “profile”, and “email”.
Wrapping it up
At the end of the day, OIDC is just a way to make sure everyone is speaking the same language when it comes to identity. It saves you from writing custom auth logic and keeps your users’ data a lot safer. If you are building on Salesforce, chances are you are already using it without even realizing it. Start by looking at your own org’s discovery URL and see what features are supported. It is the best way to learn how this stuff works in the real world.