关于OAuth协议能否用于终端用户认证的技术疑问

Let’s break down your questions clearly—this confusion is super common, and you’re right to dig into the details!

Question A: Can OAuth authorization act as proof of authentication? #

First, let’s get the core truth straight: OAuth was never designed for user authentication—its sole purpose is to let third-party apps access a user’s resources on a service (like reading your Google Drive files) without sharing passwords.

But here’s the key inference that makes "OAuth login" work: For a user to authorize your app via an OAuth provider (like Google or Facebook), they first have to authenticate themselves with that provider. You can’t authorize an app on Google’s behalf unless you’re logged into your Google account first.

So if you trust the provider’s authentication system (and let’s be real, major platforms invest heavily in security), then a successful OAuth authorization flow tells you two critical things:

1. The user is who they claim to be (since they passed the provider’s login checks)
2. They’ve given your app permission to act on their behalf (the core OAuth function)

Now, about access tokens: Strictly speaking, an OAuth access_token is for accessing resources, not proving identity. But most major providers let you use the access token to call a user info API (like /userinfo), which returns unique identifiers and user details. You can use that data to confirm the user’s identity in your app.

For Google/Facebook specifically: Their implementation ties authorization closely to their own authentication systems, so using their OAuth flow as a basis for authentication is widely accepted and secure—even though it’s not OAuth’s original intended use.

Question B: Are sites using only "Login with [Provider]" doing it wrong? #

Absolutely not! The confusion here comes from mixing up OAuth with OpenID Connect (OIDC).

OIDC is a layer built directly on top of OAuth that’s explicitly designed for user authentication. It adds an id_token (a signed JWT) that directly proves the user’s identity, plus standardized ways to validate that token. Most sites offering "Login with Google/Facebook" are actually using OIDC, not pure OAuth—they just call it "OAuth login" for simplicity.

Even if a site is using pure OAuth (without OIDC), the flow you described is totally valid:

• Redirect user to the provider → user logs in (authenticates) → authorizes your app → you receive a token → fetch user info → create your app’s session (via secure Cookie or JWT)

As long as the provider is trustworthy (has strong security, multi-factor auth options, etc.), this inference-based authentication is safe and industry-standard. The only "wrong" case would be using an untrusted provider, or failing to validate the token properly (like accepting tokens without checking their signature or expiration).

内容的提问来源于stack exchange，提问作者Joff