What is OAuth 2.0?

OAuth 2.0: definition and importance

In the past, users handed their password to third-party applications so those could access email or calendars—a considerable risk. OAuth 2.0 solves this: the user grants an application specific access, and the password stays with the respective service. The standard has been published as RFC 6749 since 2012 and underpins many logins and interfaces.

The distinction matters: OAuth 2.0 governs authorization, that is, what an application may do. For login—who is the user?—OpenID Connect, built on top of it, is usually used. You encounter both in, for example, “Sign in with Google” or “Sign in with Microsoft”.

How OAuth 2.0 works

Four roles are involved: the user as resource owner, the application as client, the authorization server that checks the approval, and the resource server holding the protected data. The user is redirected to the authorization server, signs in there and confirms which permissions (scopes) the application receives.

The application then receives a short-lived access token and, where applicable, a refresh token to obtain new access tokens. For web and mobile apps, the authorization code flow with PKCE is the recommended method; for server-to-server connections, the client credentials flow is used. Older variants such as the implicit flow are considered outdated.

Real-world example: appointment booking with calendar access

A physiotherapy practice uses a booking system that is supposed to enter booked appointments automatically into the therapists’ Google or Outlook calendars. In the past, credentials would have had to be stored for this; today, an approval via OAuth 2.0 is enough, and the password never reaches the booking system.

The therapist confirms once that the system may create calendar entries—and nothing more. She can revoke access at any time without changing her password. The system stores only the tokens, ideally encrypted, and automatically requests new ones when they expire.

Benefits, limits and common mistakes

OAuth 2.0 separates password and access, allows finely graded and revocable permissions and is widely supported. But the standard is a framework with many variants, and security gaps easily arise during implementation, because details such as redirects and token storage are your own responsibility. Typical mistakes:

• Using outdated flows such as the implicit flow or the password grant
• Storing tokens in source code, in URLs or in plain text in the database
• Requesting overly broad scopes instead of only the necessary rights
• Not defining and checking redirect URIs exactly
• Confusing OAuth with login and leaving out OpenID Connect

What businesses should look out for

Rely on vetted libraries and recognized identity services instead of home-built solutions, request only the necessary rights and plan for token revocation and rotation. Nano Concepts connects services such as Microsoft, Google or industry platforms via OAuth 2.0 and secures the interfaces in portals and apps.