OAuth Scope

Many programs want to access data that resides with another service. For example, a scheduling app might want to read your Google Calendar. To make this possible, you don’t give the app your password; instead, you grant access through a login procedure called OAuth. This procedure precisely records which actions are permitted: reading the calendar, yes; deleting emails, no. These individual permissions are called scopes. A scope is thus a short, technical label for a specific privilege that you grant to a third-party app.

Why a calendar tool shouldn’t be able to read your inbox

Without scopes, there would only be two states: no access or full access. That would be like giving a repairman not just the key to the basement, but the master key to the entire house. Scopes turn this into a gradation. The app only gets the key to the room it actually needs to work in.

This above all limits the damage if something goes wrong. If the app’s provider gets hacked, attackers can only do what the scope allows. Access that is limited to reading calendar entries is worth far less to criminals than access that can send emails. Experts call this principle least privilege: as few rights as possible, as many as necessary.

For you as a user, scopes are also the only honest piece of information about what an app really intends to do. If a simple game asks for permission to modify your contacts, that doesn’t add up. This is exactly why it pays off to read the consent screen instead of clicking it away.

From the request to the access token

The process starts with the app. It sends you to the provider, say Google or GitHub, along with a list of the desired scopes. This list consists of fixed text strings defined by the provider. Typical examples are “repo” for access to code projects or “calendar.readonly” for read-only access to the calendar.

The provider then shows you a screen asking whether you consent. If you say yes, it issues the app what’s called an access token. This is a long, random string of characters that functions like a temporary ID card. This ID card has the approved scopes permanently noted on it.

From now on, the server checks with every single request whether the matching scope is present in the token. If the app tries something it doesn’t have permission for, it gets an error message instead of the data. It’s important to distinguish this from authentication: authentication clarifies who you are. The scope clarifies what is allowed afterward. Only both together add up to meaningful access control.

Scopes in login windows and security alerts

You see scopes more often than you think. Every window headed “This app would like to access …” is a list of scopes phrased in plain language. The bullet points underneath, such as “View your email address” or “Manage files in your Drive”, are translated scope names. In your account settings, you can usually revoke these permissions again as well.

In tech news, scopes come up mainly in connection with security incidents. Access tokens from developer services are stolen again and again. The crucial question then is: which scopes did these tokens have? If they were read-only rights, the damage is limited. If they allowed write access to source code, malware can be injected into projects.

This topic is also becoming important with AI applications. Assistants are meant to answer emails, book appointments, or edit documents. For that, they need scopes with genuine write permissions. A common misconception is that a scope granted once remains harmless because you barely use the app anymore. In fact, the permission remains in effect until you actively revoke it.