Auth & Authorization

Authentication is knowing who you are. Authorization is knowing what you are allowed to do.

Authentication (AuthN)

How do we log users in?

Basic Auth

Sending the username and password with every single request. Not very secure unless used with HTTPS.

Session/Cookie Auth

1. User logs in.
2. Server creates a “session” ID and stores it.
3. Server sends the ID to the browser in a Cookie.
4. Browser automatically sends the Cookie on next visits.

Token-Based (JWT)

JSON Web Token is a standard (RFC 7519) for representing claims securely.

1. User logs in.
2. Server creates a signed JWT (a long string) containing user info.
3. Server sends it to Client.
4. Client stores it (e.g., Local Storage) and sends it in the Header (Authorization: Bearer <token>).

Pros: Stateless (Server doesn’t need to store sessions). Good for mobile and microservices.

OAuth

Using other services to log in (e.g., “Log in with Google”).

Mentions:

• OpenID Connect (OIDC): Built on OAuth 2.0, adds a standard identity layer (who the user is).
• SAML: Often used in enterprise Single Sign-On (SSO) for internal tools.

Authorization (AuthZ)

Once logged in, what can they do?

• RBAC (Role-Based Access Control): Assign roles (Admin, Editor, User). Permissions are attached to the Role.
• ABAC (Attribute-Based): More complex rules (e.g., “Can edit if document belongs to user AND it is a weekday”).
• ACL (Access Control List): Permissions are stored per resource (e.g., “this document can be read by Alice and Bob”).

References

• JWT.io
• OAuth 2.0 Explained