OAuth 2.0 vs. OpenID Connect: Understanding Authorization and Authentication

Stop managing passwords for every single user; it is a security nightmare that you don't want to own.

In the early days of the web, if a third-party app wanted to access your data from another service, you often had to give that app your actual username and password. This was a catastrophic security flaw. OAuth 2.0 and OpenID Connect (OIDC) were created to solve this problem, allowing users to grant access to their data without ever handing over their primary credentials.

While often mentioned in the same breath, OAuth 2.0 and OIDC do two very different things: one handles authorization, and the other handles authentication.

OAuth 2.0: The Valet Key of the Internet

OAuth 2.0 is an authorization framework. Its job isn't to prove who you are, but to determine what you are allowed to do.

Think of OAuth 2.0 like a valet key for a car. A valet key allows the driver to park the car and lock the doors, but it doesn't allow them to open the trunk or access the glove box. You aren't giving the valet your master key (your password); you are giving them a limited-access token.

How it Works: The Flow

The OAuth process involves four primary roles: 1. Resource Owner: The user (you). 2. Client: The application requesting access (e.g., a scheduling app). 3. Authorization Server: The server that verifies the user and issues tokens (e.g., Google or GitHub). 4. Resource Server: The server holding the data you want to access (e.g., Google Calendar API).

The typical flow looks like this: - The Client asks the User for permission to access specific data (Scopes). - The User authenticates with the Authorization Server. - The Authorization Server sends an Authorization Grant back to the Client. - The Client exchanges this grant for an Access Token. - The Client presents the Access Token to the Resource Server to get the data.

OpenID Connect (OIDC): The Identity Layer

If OAuth 2.0 is a valet key, OpenID Connect is an ID card.

While OAuth 2.0 tells the app what it can do, it doesn't actually tell the app who the user is. Developers tried to hack OAuth to do identity (using the /me endpoint), but this was inconsistent and insecure. OIDC was built as a thin layer on top of OAuth 2.0 to standardize identity.

OIDC introduces a new type of token: the ID Token.

The ID Token (JWT)

Unlike the Access Token (which is usually an opaque string meant for a machine), the ID Token is a JSON Web Token (JWT). It is designed to be read by the client application. It contains "claims" about the user, such as: - sub (Subject): A unique identifier for the user. - iss (Issuer): Who issued the token. - iat (Issued At): When the token was created. - email: The user's email address.

OAuth 2.0 vs. OIDC: A Quick Comparison

Putting it into Practice with Python

In the Python ecosystem, you rarely need to build these flows from scratch. Implementing the handshake manually is error-prone and risky. Instead, developers rely on battle-tested libraries.

Recommended Tools

• Authlib: A comprehensive library that supports both OAuth 2.0 and OIDC. It is widely considered the gold standard for Python developers.
• PyJWT: Essential for decoding and verifying the ID Tokens provided by OIDC.
• Flask-Dance / Django-allauth: Higher-level wrappers that integrate these flows directly into popular web frameworks.

A Simple Logic Example

When implementing a "Login with Google" button, your Python backend logic generally follows this pattern:

1. Redirect: Send the user to the Google OAuth endpoint with scope="openid profile email".
2. Callback: Google redirects the user back to your app with a code.
3. Exchange: Your server sends that code back to Google in exchange for an id_token and an access_token.
4. Verify: Use PyJWT to verify the signature of the id_token to ensure it actually came from Google.
5. Session: Extract the sub (user ID) from the token and start a local session for the user.

Summary

Understanding the distinction between OAuth 2.0 and OIDC is the difference between a secure application and a vulnerable one. Use OAuth 2.0 when you need to access an API on behalf of a user, and use OpenID Connect when you need to log a user into your system. By leveraging these standards, you offload the burden of password management to providers who have the resources to secure them properly.