OAuth 2.0 Fundamentals

__omp_shell("")

OAuth 2.0 is a delegation framework. It lets one application obtain limited access to another application's protected resources without asking the user to hand over their password. That is the core idea. If a calendar app wants to read your Google calendar, the safe model is not "type your Google password into the calendar app". The safer model is "let Google issue a token with limited permissions".

There are four roles to keep straight. The resource owner is usually the user. The client is the application requesting access. The authorisation server authenticates the user and issues tokens. The resource server hosts the API or data being accessed. In many products, the authorisation server and resource server are operated by the same company, but they serve different purposes in the protocol.

The result of the flow is usually an access token. That token is not a magic proof of identity in the abstract. It is a bearer credential that grants some defined scope, such as reading a profile or posting a message, for a limited time. Because the token is scoped and short-lived, the user can authorise a client without giving it full account control. Refresh tokens may also exist so a client can obtain new access tokens without asking the user to log in again every hour.

OAuth is often mentioned alongside single sign-on because delegated access and sign-in frequently appear together, but they are not identical. OAuth is mainly about authorisation. Identity information is more formally standardised through OpenID Connect, which builds on OAuth 2.0. In practice, many product teams blur the terms because the user experience often feels like "sign in with X".

The important operational benefit is separation of trust. The client never needs to store the user's third-party password, and the user can revoke access for one client without changing their entire account password everywhere. The authorisation server can also show consent screens so the user knows exactly which permissions are being requested.

There are still failure modes. If scopes are too broad, the token becomes more dangerous than intended. If redirect URIs are misconfigured, tokens or codes may be sent to the wrong place. If access tokens are stored insecurely in a browser or mobile app, an attacker may steal them even though the password was protected.

So the simple explanation is this: OAuth 2.0 lets an application say, "please let me act on the user's behalf, but only within these limits," and lets the trusted identity system decide whether that request should be granted. It is powerful because it narrows trust instead of spreading passwords around the ecosystem.