OAuth Without Tears

Riverport Planner — the tourism board's trip planner from Chapter 1 — can show a rider their own Tandem history right inside it — every trip, dates and stations, without the rider ever telling Planner their Tandem password. That is not a special deal between two companies. It is a standard ritual with a name that has scared more beginners than any other word in this book: OAuth.

OAuth is a way for you to let one app use part of your account at another service, without handing over your password. Think of the valet key some cars come with: it starts the engine and opens no trunk, the owner hands over a key rather than the key, and can demand it back. OAuth mints valet keys for online accounts. This page teaches the ceremony and skips the diagrams; you are here to read consent screens with your eyes open, not to build one.

App sends the rider to Tandemnot a form inside the app

→

Rider consents at Tandemallow: rides:read

→

App receives a scoped tokenthe valet key

→

App reads the ridesand nothing else

The Problem It Solves

Before this ritual existed, there was one way to let app B use your account at service A: give B your A password. People did it constantly, and it was as bad as it sounds. B could then do anything you could do — read everything, change everything, delete everything — for as long as it liked, invisibly, and the only way to take the permission back was to change your password and break every other thing that used it.

Three problems in that arrangement, and OAuth is the fix for all three. The trust was total, when you only wanted to share one thing. It was invisible, so you could not see afterwards what you had agreed to. And it was irrevocable in any practical sense. A ritual that grants a narrow, listed, revocable permission solves each one directly.

The Ceremony, in One Story

Follow a rider called Ana through it. In Riverport Planner she taps "Connect your Tandem account." Planner does not show her a password box; it sends her to Tandem's own page, at Tandem's own address, which is the first thing worth noticing — the page asking for her password belongs to the company that owns her password.

She signs in there, at Tandem, as she has a hundred times. Tandem then shows her a screen that names two things: the app asking, and exactly what it wants. Riverport Planner would like to read your rides. She taps Allow, Tandem sends her back to Planner, and Planner receives a token — the same kind of expiring credential as the last page, now carrying a story about who granted it and for what.

What Planner never receives is her password. It never sees it, never stores it, and could not use it if it wanted to. That is the entire point of routing her through Tandem's door instead of asking her at its own. Everything after that click is the token doing exactly the job listed on the screen, against Tandem's /riders/me resource — the rider's own profile and history, which Chapter 1 said was locked for reasons that would become satisfying.

Scopes Are the Fine Print

The single most useful sentence on that consent screen is the list of powers. rides:read is why Planner can list Ana's trips and cannot rent a bike in her name. It is the same word from the key pages, doing the same job, now printed on a screen for a non-technical person to approve — which means the fine print is finally in front of the one person it protects.

So read it. Not because most apps are lying about what they want, but because the ones that ask for more than they need are visible in that list and nowhere else. An app that only needs to show your trips and requests permission to start rides has told you something about itself, in writing, before you press the button.

What You Actually Do With This

Three things, all of them within reach today. Read consent screens like short contracts, since they are. Know where your grants live: essentially every consumer service that offers this has a page in account settings listing which apps you have connected and a button to disconnect each one, and that button works whether or not the app cooperates. And recognize the ceremony when it happens — the redirect to another company's domain and back is visible in the browser's address bar, and it is visible in DevTools from Chapter 3 as an ordinary sequence of requests.

What is deliberately not here: the mechanics. There are several flavors of this exchange, an endpoint that hands out the tokens, and a set of rules about what may be sent where. That machinery belongs to whoever is building the app, and this book hands it over by name to the Backend Deep Dive course, when it ships. As a consumer you need the shape, the screen, and the revoke button, and you now have all three.