OAuth 2.0 explained for business owners and product managers

Years ago, an app that wanted your calendar asked for your Google password, logged in as you, and could read your mail, change it and keep access forever. Nobody could tell it to stop. Handing over a password is like giving a contractor your master key when all they needed was to water the plants on Tuesday.

OAuth removes the password from the exchange. You sign in on Google’s own page, Google asks whether this app may see your calendar events, and the app only ever receives a token.

This is why a booking tool can write to a customer’s calendar while knowing nothing about how that customer signs in, whether by password, passkey or company login.

The standard names four parties. The resource owner is the person whose data it is, and the client is your app, the one asking for access to that data. The authorization server is where the person signs in and approves, while the resource server holds the data and answers every API call.

In a Google or Microsoft connection, the authorization server and resource server often belong to one company, while a smaller vendor’s product may run them as two systems. A common confusion comes from products where your company is both client and data owner, such as a staff portal reading your own Microsoft tenant.

Knowing which role is which settles most arguments. If a screen asks for a password, you are looking at the authorization server, but if a form inside your app asks for that password, something is wrong.

A scope is a single named permission, such as reading calendar events or creating invoices, and the consent screen shows each one in plain words. The person can refuse.

Ask for the smallest set that works. A scheduling feature needs to create events, not to read every contact, and wide scopes frighten users who have never heard of your company before. Some vendors send apps that request sensitive scopes through a manual review before launch, where reviewers read the scope list against your privacy policy. An unexplained scope often gets rejected.

Treat scopes as a product decision. Every extra scope is another line on the consent screen and another reason for a customer to click cancel before your feature has shown its value.

After approval, the app receives an access token. It is a long string the app attaches to each API call, and it works for a short time, often under an hour. A leaked one soon stops working.

A refresh token lets the app request a new access token without bothering the user, and because it lasts much longer it must stay encrypted on the server. It never belongs in a browser.

Both can be revoked. When a staff member leaves, or a customer disconnects the app from their Google account page, the tokens stop working at once. Show a reconnect message, not a blank error. Plan for the quiet failures too, such as a customer who changes their Google password, which in some setups cancels every refresh token your app holds for them.

Start with a list of every connection you want, such as calendar, accounting package and email, and for each one read the vendor’s developer documentation. Note the scopes, review rules and token lifetimes. They differ more than people expect.

Then decide who owns the connection. A token tied to one employee’s account breaks the day that person leaves, so use a service account or an admin consent where the vendor allows it. Where the vendor offers a sandbox with dummy accounts, build against that first, because testing consent screens on live customer data is how calendars get filled with junk.

Finally, write down what happens when a token fails: who is told, how the user reconnects and which screen they see, then build it in the first sprint. Do not leave it until launch week.