OAuth

Sometimes a program needs to access data on your behalf that resides with another provider. A photo-printing service, for example, might want to fetch the pictures from your Google account. The naive solution would be to give the service your Google password. That would be dangerous, because with it the service could do anything: read mail, delete files, change the password. OAuth solves this problem differently. You log in directly with Google, and Google then gives the service only a narrowly limited permission – for instance, “may read photos”, nothing else.

Why the password is never handed over

A password is a master key. Whoever has it is, as far as the service is concerned, indistinguishable from you. That is exactly the core problem with shared passwords: rights cannot be restricted, and access can hardly be revoked again. A password change would also lock out all other programs at once.

OAuth therefore separates two things that used to be mixed together: proof of who you are, and permission to do something specific. The proof stays with the large provider where you already have an account. The permission is issued as its own small key. In technical terms, this key is called a token, a kind of digital voucher.

For users, this means more control. In the account settings of large providers there is a list of all connected apps. Any single connection can be cut off there with one click, without anything else breaking. For companies, OAuth is also a prerequisite for software to be able to work together cleanly at all – without this standard, every provider would have to invent its own procedure.

The process with redirection and tokens

The procedure involves four parties: you as the user, the requesting app, the provider holding your data, and its login page. The process begins with a redirect. The app sends you to the provider’s genuine login page. You enter your password there, and only there, where it belongs.

The provider then shows a consent dialog. It states which rights the app is requesting. This list of rights is called scopes; one scope might mean “read calendar”, for example, and another “modify calendar”. Only once you agree are you redirected back to the app, and the app receives its token in the background.

This access token is deliberately short-lived, often valid for only minutes or hours. Alongside it there is usually a second, long-lived token that lets the app quietly obtain a new one. If a short-lived token is stolen, the damage is limited in time. It’s important to distinguish this from a related concept: OAuth governs permissions, while OpenID Connect, built on top of it, serves to confirm your identity.

The “Continue with Google” button and the API economy

OAuth is most commonly encountered when logging in. Buttons like “Continue with Google”, “Sign in with Apple”, or “Log in with GitHub” are built on it. It works the same way when accounting software looks at your bank account or a scheduling app reads your calendar. AI assistants use it too, when they are meant to search through mail or documents with your permission.

The term comes up in the news when platforms rework their interfaces. An interface, usually called an API, is the regulated access point for other programs. Whoever controls this access via OAuth can very precisely determine which partners are allowed to see what. Changes to it have already destroyed entire business models, such as when Twitter sharply restricted access for third-party apps.

A common misconception is to consider OAuth invulnerable. Attackers build fake consent pages or trick users into granting an innocuous-looking app too many rights. Protection therefore comes down to reading carefully: check the address of the login page and the list of rights displayed. And occasionally clean up the list of connected apps.