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

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.

  👉 That’s OAuth: “This app can access some of my data or services.”

• OIDC is like asking the hotel to check who the person is before giving them access.

  So your friend also shows an ID card — and now the hotel knows their name, status, and that they’re a verified guest.

  👉 That’s OIDC: “Here’s who the user is, and they’re now signed in.”

How Logto uses OAuth 2.0 and OpenID Connect (OIDC)#

Logto’s core authentication features are built on top of OIDC (OpenID Connect)#

At its core, Logto is an OpenID Connect (OIDC) provider — a standard built on top of OAuth 2.0 that focuses on secure, modern user authentication. Logto is a professional CIAM solution, where identities are the core building blocks we manage.

We’ve designed Logto with security as a foundation. That means enforcing PKCE by default, blocking insecure flows like the implicit flow, and relying on redirection to handle sign-ins safely.

Why redirection?#

OIDC is meant for browser-based authentication. It’s not just a technical choice — it’s about giving users a secure, consistent experience across platforms. Redirecting the user to the identity provider (like Logto, Google, or Microsoft) helps make that possible.

Here’s what the typical flow looks like:

1. User clicks “Sign in”

   → Your app sends them to Logto’s login page.

2. They log in securely

   → This is where things like MFA, biometrics, or social sign-ins happen.

3. Logto sends them back

   → Along with a secure token or authorization code.

4. Your app completes the login

   → The token is verified, and the user is signed in.

This pattern may seem simple, but it brings powerful benefits:

• Your app doesn’t handle credentials directly — which means fewer risks.
• It’s easier to add features like MFA without changing app code.
• It works great for mobile, too:
  • iOS uses ASWebAuthenticationSession
  • Android uses Custom Tabs

And if your product spans multiple apps, Redirection allows for single sign-on — users sign in once, and move between apps without friction.

Logto doesn’t support collecting passwords directly in your app. That’s intentional. The ROPC flow is not recommended for OAuth 2.0 security best practices for good reasons — it’s less secure and harder to scale safely.

Logto is also a OAuth 2.0/OIDC provider (Identity Provider)#

Logto is more than just an authentication server — it’s a full OAuth 2.0, OpenID Connect (OIDC), and Identity Provider (IdP). That means it can securely manage user identities and issue tokens that other applications can trust.

In addition to powering login experiences for your own apps, Logto also supports third-party application integrations, letting external services rely on Logto as their identity source.

What does that mean in practice?

As an Identity Provider (IdP), Logto handles user verification, manages credentials, and issues authentication tokens. Once a user signs in, Logto can let them access different apps — even from other vendors — without logging in again. It’s the same concept behind “Sign in with Google” or “Sign in with Microsoft”.

There are two kinds of applications in this context:

• First-party apps: Apps you build and fully control, integrated directly with Logto.
• Third-party apps: External services built by partners or developers outside your organization.

Logto enables your users to sign in to these third-party apps using their existing Logto accounts — just like enterprise users sign into tools like Slack with their Google Workspace credentials. This allows you to:

• Offer single sign-on (SSO) across your ecosystem.
• Build an open platform, where third-party developers can add “Sign in with Logto” to their apps.

When do you really need OAuth 2.0 and OIDC?#

1. If you’re previously using Auth0 (or similar): Auth0 is already an OAuth 2.0 and OIDC provider. It manages user login, token issuance, and integrates with your APIs or apps.
2. M2M authorization: Server-to-server (client credentials flow) Machines (or backend services) need to communicate securely without a user.
3. Device flow: Smart TVs, consoles, IoT devices: Devices like TVs or printers need to authenticate a user. Device flow is part of the OIDC.
4. You have the interation needs: You’re not just authenticating users — you’re creating an ecosystem where external apps, partners, or agents can integrate with your platform and access user data securely.

Why OAuth and OIDC matter more than ever in the AI era#

In the AI era, we’re seeing a surge of new integration and access needs — especially in areas like autonomous agents, smart devices, and system-to-system communication. These trends are making OAuth 2.0 and OIDC more important than ever. Here are a few examples:

1. Remote MCP servers

   You build a remote MCP (Model Context Protocol) server and want third-party agents to connect to it. These agents need secure access to request context, perform actions, and exchange data — all without compromising user trust. OAuth provides the mechanism to delegate access safely.

2. Opening up your product to integrations

   You run your own business services — say a project management tool or a customer platform — and you want to let other products or agents integrate with it. That might mean pulling data, triggering workflows, or embedding your features into other environments. OAuth 2.0/OIDC enables fine-grained, token-based access control without sharing user credetials.

3. Building your own agent

   You’re creating an AI agent or assistant and want it to interact with other apps and MCP servers — scheduling meetings, sending emails, posting updates, or querying data. These require secure, authenticated access to third-party services. OAuth 2.0 is how your agent gets authorized to act on behalf of the user.

4. The rise of smart devices

   Hardware devices like AI translators or smart meeting note-takers are becoming more capable thanks to LLMs. And with lower cost and higher performance, more of these devices are hitting the market. These devices often need a way to authenticate users and access cloud-based services — especially with limited input interfaces. That’s where flows like OAuth’s device authorization flow and OIDC-based identity validation become critical.

When you might not need OAuth 2.0/OIDC#

Of course, there are cases where you might not need OAuth 2.0 or OIDC — at least not right now. In other words, if your current use case is simple or fully self-contained, these protocols might not bring immediate value.

However, as your product grows or your ecosystem expands, the need for OAuth 2.0 and OIDC often becomes much more apparent in the long run.

1. Simple, internal apps

   If your app is only used by a small team inside a company and doesn’t need to integrate with third-party services or expose APIs, a basic username-password auth system (e.g., cookie sessions) might be enough.

2. No user authentication needed

   If your product doesn’t have user accounts or identity-aware features—such as a public content site or a server-to-server tool with static API keys—OIDC isn’t needed.

3. No delegated access required

   OAuth shines when you need users to authorize your app to access their data in another system (e.g., Google Drive). If you’re not integrating with third-party APIs or building multi-service workflows, OAuth adds complexity with little value.

4. Single environment, minimal risk

   For early-stage prototypes, MVPs, or internal test tools where simplicity and speed outweigh security needs, you might delay implementing OAuth/OIDC until later.

Final thoughts on picking the right auth strategy#

You might not need OAuth 2.0 or OIDC right away — and that’s completely fine. In the early stages, simple solutions often get the job done. But as your product grows, as agents and AI become more integrated into how we build, and as your ecosystem opens up to partners and third parties, secure and standardized authentication becomes less of a nice-to-have and more of a must.

Instead of playing catch-up later, it’s worth laying the foundation now. Adopting OAuth 2.0 and OIDC isn’t just about solving today’s problems — it’s about being ready for what’s coming next.