What Is OAuth?

OAuth is a standard that lets you grant one application limited access to your data on another service, without ever handing over your password. Instead of typing your Google password into a random app, that app asks Google directly for permission, and Google hands it a narrow, revocable token instead of your login.

This is called delegated authorization: you delegate a specific, limited permission, not your full identity. It is the mechanism behind almost every “log in with” button and every app that connects to your calendar, photos, or contacts.

The three parties in an OAuth flow.

Every OAuth exchange involves three separate roles, even though a user usually only sees one screen.

• The client: the app or website asking for access, such as a scheduling tool that wants to read your calendar.
• The authorization server: the service that owns your login, such as Google or GitHub, which checks who you are and what you agree to share.
• The resource server: the system that actually holds the data being requested, often the same company as the authorization server but a distinct role in the protocol.

Keeping these roles separate is what makes OAuth work. The client never touches your password, because the authorization server is the only party that ever sees it.

How the flow works, from click to token.

When you click “connect” or “log in with” a provider, the client redirects you to the authorization server’s own site. You log in there, on a page you already trust, and you see a consent screen listing exactly what the client is asking to access, such as your email address or your calendar events.

If you approve, the authorization server sends the client a code, which the client exchanges for a token, a piece of data proving it has permission to act on your behalf for a defined purpose and a defined amount of time. That token carries a scope, which limits exactly what it covers. A calendar app might get a scope that only allows reading events, not sending email or deleting your account. Unlike a password, a token can expire and can be revoked from your account settings at any moment.

Log in with Google or GitHub as an everyday example.

The “log in with Google” or “log in with GitHub” button on a signup page is OAuth in its most common form. Instead of creating a new username and password for every service, you authorize that service to confirm your identity through an account you already have.

Behind that one click, the same three-party flow runs: the new site is the client, Google or GitHub is the authorization server, and a small resource, usually your name, email, and profile picture, is the data being shared. You get a faster signup, and the new site never has to store a password for you at all.

OAuth versus passwords.

A password is a shared secret: you and the service both know it, and anyone who learns it can act fully as you, indefinitely, until you change it. OAuth replaces that shared secret with a token that is narrower in scope, easier to revoke, and never typed into the client application at all.

This matters most when you connect a third-party tool to a service that holds something sensitive, like your email or your files. Handing that tool a password would give it everything. Handing it an OAuth token with a specific scope gives it only what it actually needs, and you can take that access back without changing anything else about your account.

Where to start if you are implementing OAuth.

Most developers never build OAuth from scratch. Instead, you register your application with the provider, such as Google, GitHub, or Microsoft, receive a client ID and secret, and use an existing library for your language or framework to handle the redirect, the token exchange, and the refresh logic.

The details that matter most early on are choosing the narrowest scopes your app actually needs, storing tokens securely rather than in plain text, and handling token expiration and refresh so users are not asked to reauthorize constantly. Getting those basics right covers the vast majority of real-world OAuth integrations.

My work finally matches the pace of my thinking, which sounds small until you remember how many good ideas used to die waiting for someone to build them.

Itamar Haim

Where Sticklight fits

Sticklight is a vibe-coding platform built for professional web creators: you describe what you want in plain language, and it turns that prompt into a production-ready result, whether that is a website, an app, a dashboard, a small content system, or a working tool. When a project needs a “log in with” button or a connection to an outside service, Sticklight can help scaffold that authorization flow as part of the build, instead of leaving you to wire it up by hand.

That range is the point. Sticklight is built to go beyond a single website and toward being a full-stack creator, handling pieces like authentication and third-party connections that used to mean separate tools and separate setup. WordPress and Elementor remain solid ways to extend what a site can do, and Sticklight adds a faster, prompt-first path alongside them for building everything from a landing page to a full application.

Frequently asked questions

What is OAuth in simple terms?

OAuth is a standard that lets you grant an app limited, revocable access to your data on another service, without ever sharing your password with that app.

What is the difference between OAuth and single sign-on?

OAuth is the authorization protocol that grants access to specific data or actions, while single sign-on uses that same kind of flow mainly to confirm your identity, such as logging into a new site with an existing Google account.

What is a scope in OAuth?

A scope is the specific permission a token carries, such as read-only access to your calendar, and it limits exactly what the requesting app is allowed to do with your data.

Can I revoke OAuth access after granting it?

Yes, most providers let you review and revoke any app’s access from your account security settings at any time, which immediately invalidates its token.

Is OAuth the same as an API key?

No, an API key is usually a single static credential you keep secret, while OAuth issues short-lived tokens tied to a specific user, scope, and consent decision that can expire or be revoked independently.

Built by the Elementor team. Powered by Claude.

Let it glow.