Learning: Model OAuth 2.0 delegated authorization

[code811]

Learning: Model OAuth 2.0 delegated authorization

Purpose

Develop the OAuth 2.0 mental model required before connecting the outreach reporting system to Gmail.

Learning Goals

• Distinguish authentication from authorization.
• Explain delegated authorization.
• Identify the OAuth actors in this project.
• Explain the authorization-code flow.
• Distinguish authorization codes, access tokens, and refresh tokens.
• Explain OAuth scopes and least privilege.
• Understand why tokens must be treated as sensitive credentials.
• Identify how authorization requirements can affect system architecture.

Tasks

• Create learning/notes/oauth-2.md.
• Explain authentication vs authorization in my own words.
• Identify the resource owner, client, authorization server, and resource server for this project.
• Draw the project's OAuth authorization-code flow.
• Explain the purpose of an authorization code.
• Explain the purpose of an access token.
• Explain the purpose of a refresh token.
• Explain what an OAuth scope restricts.
• Explain the principle of least privilege.
• Explain why scheduled reports could require a different authorization architecture than manually generated reports.
• Complete the retrieval exercises from Lesson 2.

Constraints

• Do not connect a real Gmail account yet.
• Do not create production OAuth credentials yet.
• Do not store or commit any tokens or secrets.
• Focus on the mental model rather than Google-specific implementation syntax.

Completion Criteria

I can reconstruct the OAuth authorization flow without notes and correctly explain:

Resource Owner → Client → Authorization Server → Authorization Code → Tokens → Resource Server

I can also distinguish authentication from authorization and explain why the application should request only the minimum Gmail permissions necessary.

[code811]

Completed By:
Retrieval questions for Lesson 2 are found under 2.) Core Questions inside Lesson 2 — Authentication, Authorization, and OAuth 2.0
Answers to the questions:

A.) For the MVP of the outreach project: the resource owners are the outreach team members, the client will be the outreach tracking program, the authorization server will be Google Authorization Server, and the Resource server will be Gmail API.
B.) The authorization code is used to confirm that the resource owner allowed specific permissions, while the access token grants the client those permissions inside the resource server.
C.) If the access token expires, the refresh token is used similar to the authorization code through the authorization server to grant the client another access token. This new temporary access token is used by the client to access Gmail specific API requests.
D.) By extending permissions past what requirements ask for, we've violated the least privilege concept. Even if the code doesn't intentionally delete anything, because it's granted permission of this power, this means there's always a possibility it can, especially in cases where the access token, or even the refresh token, is leaked and others can use it themselves.
E.) Requirement B requires additional OAuth/storage/security requirements, as now the program must store a refresh token. Due to the long-lived nature of refresh tokens, it's much more severe and sensitive. The program must also take into account the possibility that the refresh token becomes unusable.
F.) Google authenticated Alice, as she successfully signed in. Because Alice canceled, she did not authorize our application. This means that our application does not receive Gmail access. This leads to authorization not being granted, or a 403 Forbidden status code if we attempt a request to the Gmail API.

Lesson 2 — Authentication, Authorization, and OAuth 2.0

[code811]

Correction to F.):
The status code 403 Forbidden is not sent when attempting to request to the Gmail API due to Alice never allowing authorization. This means that the request would have never been able to be sent.
403 Forbidden only occurs when authentication and authorization is present, however the program attempts to access resources which weren't explicitly authorized by the resource owner.