OAuth Application

Imagine you want to allow an app to read your Spotify playlists – but you don’t want to give it your Spotify password. OAuth (short for “Open Authorization”) solves exactly this problem. It is a mechanism that lets a user grant a third-party application access to their data on another service. The application requesting this access is called an OAuth application. In return, it receives a time-limited key, known as an access token, but never the actual password. This protects the user: even if the OAuth application is compromised, the account at the actual service remains safe.

Granting access rights without sharing passwords

Before OAuth, the situation was dangerous. If an app wanted to access someone else’s data, it simply asked for the password. Users handed it over – and lost all control in the process. The third-party app could do anything the user themselves could do: read, change, delete data.

OAuth cleanly separates identity and authorization. The user retains possession of their password. The OAuth application only gets what was explicitly granted – and only for a certain period of time. Many services also allow individual access tokens to be revoked afterward. This means: anyone who distrusts an app can withdraw its key without having to change their own password.

This is especially important for developers. Anyone building their own application that accesses user data must handle that data responsibly. OAuth makes this technically enforceable: the service holding the data decides for itself which types of access it even permits for OAuth applications.

The process behind the “Sign in with Google” button

An OAuth application starts the process by redirecting the user to the service’s login page – for example, Google or GitHub. There, the user logs in with their own credentials. The service then shows exactly which permissions the application wants to have: for example, “read email address” or “write calendar entries”.

If the user agrees, the service sends a short-lived code to the OAuth application. The application exchanges this code in the background for an access token. From this moment on, the application can access the data within the scope of the granted permissions – without ever having seen the password. The token expires after a set period of time or can be revoked manually.

A common misconception: OAuth is not a login mechanism, but an access authorization mechanism. When you log in to a third-party website using “Sign in with Google,” that website uses OAuth to prove that you own a valid Google account. The actual login part is handled by an extension called OpenID Connect, which is built on top of OAuth. The two terms are often conflated in everyday use.

OAuth applications in products, news, and developers' daily work

Every time an app asks “May this application access your account?”, OAuth is very likely behind it. This applies to social media dashboards like Buffer, which post to Twitter or Instagram on the user’s behalf. It applies to code tools like GitHub Actions, which access repositories. And it applies to AI assistants that access Google Drive or Outlook to summarize documents.

In the financial world, OAuth comes up in the context of open banking. Here, users grant a financial app permission to retrieve their account data directly from the bank – via standardized interfaces based on OAuth. The app sees the account balance, but never the banking credentials themselves.

In tech news, the term often appears in connection with security incidents. If attackers register an OAuth application with broadly scoped permissions and trick users into approving it, they can gain persistent access to accounts – entirely without a phished password. Large platforms like Microsoft and Google have therefore begun requiring OAuth applications to be approved by corporate administrators before employees are allowed to use them.