Why your product needs OAuth 2.0 and OIDC — Especially in the AI era

This article is created by Logto, an open-source solution that helps developers implement secure auth in minutes instead of months.

From the very beginning, Logto was built with a strong belief in open standards. We chose to follow protocols like OIDC, OAuth 2.0, and SAML — not just because they’re widely used, but because they represent well-established, secure practices trusted across the industry. Security has always been a priority for us. So has staying true to the spirit of open source, and adhering to best practices in Customer Identity Management and modern authentication.

But we also learned something along the way:

OAuth 2.0 and OIDC aren’t easy for everyone. For developers who are new to these protocols, the concepts can feel foreign and sometimes even counterintuitive. This led to real challenges as we worked through how to simplify the developer experience without compromising on security.

Two things stood out:

1. Even though we’ve worked hard to make integration as smooth as possible, there’s still a learning curve around understanding basic concepts like ID tokens, access tokens, and how they work.
2. A common question we get is: “Can I skip the redirect on the login screen?” Unfortunately, redirection is a core part of how OIDC works and is necessary for secure authentication.

A common question from our Discord users (with their ID and avatar obfuscated for privacy).

Every decision comes with trade-offs — but sometimes, a choice you made early on turns out to be especially valuable as new use cases emerge. And we’re now entering a new era: the era of AI.

In this article, I’ll explore when your product should use OIDC and OAuth 2.0, when it might not need them, and why I’ve always advocated for adopting these open standards from the very beginning — especially if you’re building a real business and choosing a CIAM solution. I’ll also explain why the rise of AI makes this decision more important than ever.

What OAuth 2.0 really does (with a simple analogy)

For readers who aren’t very familiar with OAuth 2.0, let me take a moment to briefly go over some of the basic concepts again — just to make things clearer.

OAuth 2.0 is for delegated authorization:OAuth 2.0 is an industry-standard protocol for authorization – it allows one service to access resources on another service’s behalf with the resource owner’s consent.

In an OAuth scenario, the user (resource owner) grants a client application limited access (scoped permissions) to an API or resource server, without sharing their password. OAuth defines how to request and issue access tokens that the client can use to call protected APIs. This was a game-changer compared to early days when apps might ask for your credentials to access another service (a serious security risk). With OAuth 2.0, users approve specific access and the client gets a token with only the permissions and duration needed – no passwords are exchanged, dramatically improving security.

Think of OAuth 2.0 like checking into a hotel.

You (the user) are the owner of the room (your data). But instead of giving someone your room key (your password), you go to the front desk and ask for a temporary access card (an access token) that only works for your guest or friend to enter the gym or pool — not the whole room.

The hotel staff (OAuth system) issues this limited card with specific rules:

• It only works for the gym (specific resource).
• It’s valid for a short time.
• It doesn’t let anyone enter your room.

This way, you don’t have to give away your master key — and the system stays secure, even if someone else gets hold of that limited card.

Let’s take a look at another example. OAuth 2.0 is widely used in the social sign-in scenario.

Let’s say you’re signing up for a new app like Notion, and instead of creating a new username and password, you click “Continue with Google.”

Here’s what happens under the hood with OAuth 2.0:

1. You’re redirected to Google’s login page, where you log in (if you’re not already).

2. Google asks:

   “Do you allow this app to view your basic profile and email address?”

3. You click “Allow”, and Google sends the app an access token.

4. The app uses that token to:

   • Confirm your identity (via your email and profile info).
   • Create or log you into an account — without ever seeing your Google password.

What OIDC really does (with a simple analogy)

Now let’s take a look at OIDC — a newer and more advanced standard. OpenID Connect aims for Identity and Authentication: it is an authentication layer built on top of OAuth 2.0. While OAuth 2.0 alone doesn’t tell the application who the user is (it’s only about access tokens and scopes), OIDC adds a standard way to handle user login and identity.

When using OIDC, the authorization server also acts as an OpenID Provider (an Identity Provider) that authenticates the user and issues an ID token containing information about the user (the “identity claims”).

In short, OAuth 2.0 answers “Can this client access this resource?” and OIDC answers “Who is the user that just logged in?”. Together, they let your app verify the user’s identity and then use authorized tokens to access APIs on the user’s behalf.

Let’s use the Hotel Analogy to better understand OAuth 2.0 vs. OIDC again.

Imagine you’re checking into a hotel.

• OAuth 2.0 is like asking the hotel to let your friend use the gym and pool on your behalf.

  You go to the front desk, give permission, and the hotel gives your friend a guest pass.

  The hotel doesn’t care who the friend is — just that they’re allowed to use the facilities.