OAuth2.0

Learning Authorization

OAuth 2.0: Delegated Access Without the Password

OAuth 2.0 is an authorization framework that allows applications to access a user's protected data—without requiring the user to share their actual credentials. Instead of exposing their password, the user authorizes a limited-access token that specifies exactly what the application can do and for how long.

Imagine Anya is trying to print photos from her Google Drive using an external photo printing app. Instead of handing over her Google password, the app asks Google to confirm that she (the user) has granted it permission to access only her photo albums. That selective permission process? That’s OAuth 2.0 in action.

Why OAuth 2.0 Matters

Traditional credential sharing between systems is fragile, risky, and nearly impossible to audit. OAuth 2.0 modernizes that by introducing access delegation through tokens, improving both user privacy and security.

Its primary use case is:

• Letting a client app access protected resources on a resource server, on behalf of the resource owner, without the app ever knowing the user's credentials.

This makes OAuth foundational for secure API integrations, mobile and web apps, and any cloud-based service that needs temporary access to user data.

---

Core Components of OAuth 2.0

Resource Owner : The user whose data or resources are being accessed (e.g., Anya and her Google Photos)

Client : The third-party application that needs access to those resources (e.g., a photo editing app)

Authorization Server : The service that authenticates the user and issues access tokens (e.g., Google’s auth system)

Resource Server : The API or backend that hosts the user’s data (e.g., Google Photos API)

Access Token : A credential the client uses to access the user’s resources; limited in scope and duration

Refresh Token : A token that can be used to obtain a new access token once the old one expires

Scope : A parameter defining what actions or resources the client can access (e.g., “read contacts”, “send email”)

---

How It Works — The Simplified Flow

Here’s how Anya’s photo printing use case unfolds:

1. Consent
   The client app redirects Anya to the authorization server (Google) and requests access to a specific scope (e.g., read-only access to photos).

2. Authentication & Approval
   Anya logs into her Google account and is asked if she approves the access request. If she agrees, the process continues.

3. Authorization Code Issued
   The authorization server returns a temporary code to the client.

4. Token Exchange
   The client exchanges the code for an access token (and optionally a refresh token).

5. API Access
   The client uses the access token to call the resource server (Google Photos API) and fetch the requested data.

---

🧵 **Follow the series:** #AnyaInCyberSecurity | #CISSP | #IAM | #WomenInTech #AccessControls #CyberSecurity #InfoSec #SecurityLeadership #WomenInCyberforce #FromDevToDefender #TechLeadership #DevSecOps #CISSPDomains