OAuth 2.0.
OAuth 2.0 is an open standard that lets an application access a person's data at another service on their behalf without knowing their password. The person confirms at the service itself which rights they grant, and the application receives a time-limited access token in return.
OAuth 2.0 — Explained in Detail
Before OAuth, connecting two services was often insecure: anyone who wanted to import contacts from a mail account into another app gave that app their mail password. The app then had full access, forever, and the password sat in a third-party system. OAuth 2.0, standardised as RFC 6749 in 2012, solves this with a detour: the person signs in at the actual service, sees there which rights the app is asking for, and confirms. The app receives not the password but a token with exactly those rights.
The standard defines four roles. The resource owner is the person who owns the data. The client is the application that wants access. The authorisation server verifies identity and issues tokens. The resource server holds the data and accepts valid tokens. The granted rights are called scopes, such as 'read calendar' or 'create invoices'. The access token is short-lived; a refresh token allows new access tokens to be obtained without asking the person again. For web and mobile apps, the authorisation code flow with PKCE is today's recommended flow.
One distinction is important: OAuth 2.0 governs authorisation, meaning 'what may this app do', not authentication, meaning 'who is this person'. For signing in with an existing account, such as 'Sign in with Google' or 'Sign in with Microsoft', a separate layer is added on top: OpenID Connect. It additionally supplies an ID token with identity information. This pairing of OAuth 2.0 and OpenID Connect is also the most common technical basis for single sign-on in companies.
For SMEs, OAuth matters mainly in two situations. First, when your own application needs to read data from Google Workspace, Microsoft 365, accounting software or an advertising account: the connection is made via OAuth, and the grant can be revoked at any time in the respective account. Second, when your own platform, such as a customer portal, is meant to give other systems controlled access through an API. Then your application becomes an authorisation server itself or uses an existing identity service.
Typical mistakes in OAuth integrations
The most common mistake is scopes that are too broad: an app that only needs to read appointments asks for full write access to the mailbox because it is more convenient. That contradicts the principle of least privilege and rightly puts users off at the consent screen. The second mistake is insecure storage of refresh tokens: they are long-lived and belong encrypted in the database, never in browser storage or log files.
Third, redirect addresses are configured too loosely, which allows attackers to intercept authorisation codes. Fourth, revocation is not handled properly: if someone withdraws the grant, the application must recognise that and respond in an understandable way instead of failing with cryptic errors.
Example: appointment booking with the practice calendar
An example: a physiotherapy practice with four therapists wants its online booking to read free slots directly from their existing Microsoft 365 calendars and enter new appointments there. Instead of storing the therapists' passwords in the booking system, each connects her calendar once via OAuth. In doing so she sees at Microsoft that the booking may only read calendars and add appointments, not read emails.
If a therapist leaves the practice, her account is deactivated and the connection ends automatically. If she changes her password, the booking stays connected because it never knew the password. Integrations like this are everyday work when we develop a web app or connect custom software to existing tools.
Related Page
Single Sign-on (SSO)Frequently Asked Questions About OAuth 2.0
Not strictly. OAuth 2.0 governs which rights an application receives. For signing in with an existing account, OpenID Connect is used; it builds on OAuth 2.0 and additionally confirms who the person is. In everyday language both are often called 'OAuth login'.
A scope describes a specific right an application requests, for example 'read calendar' or 'edit contacts'. The person sees this list when granting access. Good applications ask only for the scopes they actually need.
In the account settings of the respective service, for example at Google under third-party apps with account access, or at Microsoft under app permissions. After revocation the tokens become invalid and the application can no longer access the data.
More Terms Starting with "O"
Organic Traffic
Organic traffic describes visitors who come to your website through unpaid search results — i.e., vi...
Open Graph (og: tags)
Open Graph is a meta-tag protocol that controls how a web page appears when it is shared on social n...
OpenAI Ads Manager
The OpenAI Ads Manager is the interface in which ads for ChatGPT are created, managed and evaluated....
Ready for Your Project?
Apply this knowledge to your website — DLM Digital will help you.