OAuth vs. OAuth 2.0: How They Differ and When to Use

TL;DR

OAuth 1.0 and OAuth 2.0 both let applications access protected resources without receiving a user's password, but they are not interchangeable implementations. OAuth 1.0 signs every request and is harder to deploy. OAuth 2.0 relies on TLS, short-lived access tokens, and flows designed for web, mobile, device, and service-to-service applications.

For almost every new application, choose OAuth 2.0. Use Authorization Code with PKCE for user-facing apps and Client Credentials for machine-to-machine access. For user authentication, add OpenID Connect rather than treating OAuth 2.0 as a login protocol.

Understanding OAuth 1.0

OAuth 1.0 is a delegated authorization protocol. It allows a user to grant one application limited access to another service without revealing the user's password.

For example, a publishing tool can redirect a user to a social platform to approve permission to publish posts. The platform then issues credentials to the tool. OAuth controls what an application may do, not necessarily who the user is, and users can revoke access without changing their password.

How the OAuth 1.0 flow works

OAuth 1.0 involves three principal roles:

• Resource owner: The person who owns the protected data.
• Consumer: The application requesting access.
• Service provider: The platform hosting the data and issuing credentials.

A typical flow is:

1. The consumer requests temporary credentials.
2. The user approves access at the provider.
3. The provider returns a verifier.
4. The consumer exchanges the temporary credentials and verifier for token credentials.
5. The consumer signs each API request using its client secret and token secret.

Each protected request includes a cryptographic signature, timestamp, and nonce. The provider calculates the expected signature and rejects mismatches.

Advantages of OAuth 1.0

OAuth 1.0 improved security over password sharing:

• Users grant limited, revocable access.
• Passwords remain with the original service.
• Signatures help detect tampering.
• Nonces and timestamps reduce replay risk.
• Tokens can represent limited permissions.

These protections explain why some established APIs still support OAuth 1.0. A working legacy integration may not require immediate migration.

Limitations of OAuth 1.0

Request signing increases implementation effort. Client and server must normalize parameters, construct signatures, and encode values identically. Differences in URL handling, ordering, or escaping can cause failures.

OAuth 1.0 is also poorly suited to public clients that cannot protect long-term secrets, including browser and installed applications. Its limited flow model is less flexible across mobile apps, smart TVs, command-line tools, and backend services.

OAuth 2.0 as the Modern Successor

OAuth 2.0 supports more application types with less client-side cryptographic complexity. It divides the service provider into two logical components:

• The authorization server authenticates the resource owner, obtains consent, and issues tokens.
• The resource server hosts the protected API and validates access tokens.

It also calls the consumer the client. This separation enables centralized authorization across multiple APIs.

How does OAuth 2.0 work?

The exact OAuth2 flow depends on the grant type. A user-facing flow generally follows:

User → Client → Authorization server → Consent → Authorization code → Client backend → Access token → Resource server

In Authorization Code with Proof Key for Code Exchange (PKCE):

1. The client generates a code verifier and derived challenge.
2. It redirects the user to the authorization server with the challenge and scopes.
3. The user signs in and approves access.
4. The server redirects back with a short-lived authorization code.
5. The client exchanges the code and verifier for an access token.
6. The client uses the token to call the protected API.

PKCE prevents an attacker without the verifier from exchanging a stolen code.

Access tokens are usually short-lived. A refresh token may obtain new access tokens without prompting the user again, but it requires secure storage and should use rotation or sender-constraining where supported.

OAuth 2.0 does not define identity claims. Applications requiring “Sign in with…” should use OpenID Connect. The framework is defined in RFC 6749.

OAuth 1.0 vs. OAuth 2.0: The Practical Differences

The central difference is request protection. OAuth 1.0 requires per-request signatures. OAuth 2.0 typically uses bearer tokens over TLS and offers flows for different client types.

Decision factor	OAuth 1.0	OAuth 2.0
Request protection	Signature on each request	TLS plus token validation
Application support	Primarily traditional web clients	Web, mobile, desktop, devices, and services
Client complexity	Higher	Lower with established libraries
Token lifecycle	Often longer-lived credentials	Commonly short-lived access and refresh tokens
Flow selection	One main delegated flow	Multiple grants
Best fit	Legacy integrations	Most new authorization systems

Support for non-browser applications

OAuth 1.0 assumes clients can protect credentials and create signatures, which is difficult in browser code and mobile apps where secrets can be extracted.

OAuth 2.0 supports different environments. Authorization Code with PKCE works for browser, mobile, and desktop applications without a permanent client secret. Device Authorization supports input-constrained devices such as televisions. Teams must select a flow based on the client's trust model.

A simpler protection model

OAuth 2.0 relies on HTTPS rather than requiring most clients to construct signatures. However, bearer tokens can generally be used by anyone who obtains them. Applications must enforce TLS, validate redirect URIs exactly, prevent tokens from entering URLs or logs, and protect refresh tokens.

Developers should use mature authorization-server and client libraries instead of custom security logic.

More controllable token security

OAuth 2.0 encourages short access-token lifetimes, granular scopes, and separate refresh tokens. Authorization servers can revoke or rotate refresh tokens and restrict audiences.

OAuth 1.0 signatures provide properties bearer tokens do not, so OAuth 2.0 is not automatically more secure. Its security depends on selecting the correct flow and handling tokens according to the threat model.

Choosing OAuth 2.0 Flows for Real Applications

Use OAuth 2.0 for delegated API access, centralized authorization, or short-lived credentials. Relevant OAuth2 grant types include:

• Authorization Code with PKCE: Default for user-facing web, mobile, and desktop clients.
• Client Credentials: For a confidential service acting on its own behalf.
• Device Authorization: For devices with limited input or browser capabilities.
• Refresh Token: Renews access after an initial grant; it does not establish consent independently.

Avoid the deprecated Implicit and Resource Owner Password Credentials grants in new applications.

Microservice authorization

Use Client Credentials when one backend service calls another without a user. Service A authenticates to the authorization server, receives a token scoped to an API, and presents it to Service B. Service B validates its issuer, audience, expiration, and scopes.

Do not use Client Credentials to impersonate a user. Preserve user context through a delegated-token design when a service acts for a signed-in person.

API gateway enforcement

An API gateway can validate token signatures, expiration, audience, issuer, and scopes before requests reach internal services, then pass verified context downstream.

A dedicated identity provider may issue tokens while the gateway enforces policy. Keeping these responsibilities explicit prevents internal APIs from trusting unverified claims.

How to Build an App Like This with Tencent RTC

For a calling or conferencing app, OAuth 2.0 should control application access and room permissions. It does not replace Tencent RTC's room credential.

A practical architecture has four parts:

1. An OAuth 2.0 server signs in the user and issues an access token.
2. Your backend validates the token and maps its subject to an internal user ID.
3. The backend checks room permission and generates a short-lived Tencent RTC userSig.
4. The client uses Tencent RTC Engine to enter the room and publish or subscribe to media.

Keep the Tencent RTC secret key on the server. Never generate production userSig values in browser or mobile code.

Protect a backend endpoint with OAuth 2.0 and issue room-specific credentials:

app.post("/api/rtc/session", requireOAuthAccessToken, async (req, res) => {
  const userId = req.auth.sub;
  const roomId = Number(req.body.roomId);
  await assertUserCanJoinRoom(userId, roomId);

  res.json({
    sdkAppId: Number(process.env.TENCENT_RTC_SDK_APP_ID),
    roomId,
    userId,
    userSig: generateTencentUserSig({
      sdkAppId: process.env.TENCENT_RTC_SDK_APP_ID,
      secretKey: process.env.TENCENT_RTC_SECRET_KEY,
      userId,
      expiresIn: 3600
    })
  });
});

Then use trtc-sdk-v5 in the browser:

import TRTC from "trtc-sdk-v5";

const session = await fetch("/api/rtc/session", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${oauthAccessToken}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({ roomId: 10001 })
}).then(r => r.json());

const trtc = TRTC.create();

trtc.on(TRTC.EVENT.REMOTE_VIDEO_AVAILABLE, ({ userId, streamType }) => {
  trtc.startRemoteVideo({ userId, streamType, view: `remote-${userId}` });
});

await trtc.enterRoom(session);
await trtc.startLocalAudio();
await trtc.startLocalVideo({ view: "local-video" });

Review the official Tencent RTC Engine integration documentation before implementing production room entry and media controls. Authorize every room request, use short credential lifetimes, and revoke application sessions when the corresponding OAuth authorization is no longer valid.

FAQ

Is OAuth 2.0 an authentication protocol?

No. OAuth 2.0 delegates authorization. Use OpenID Connect when the application needs standardized user authentication and identity claims.

Which OAuth2 flow should a mobile or single-page app use?

Use Authorization Code with PKCE. It protects the authorization-code exchange without requiring the public client to store a secret.

Should an OAuth access token be sent directly to Tencent RTC?

No. Send it to your backend for validation. The backend should authorize room access and return a short-lived Tencent RTC userSig to the client.