Today we're diving into the basics of OAuth2 — the authorization standard that lets you securely control access to resources. This is an important step toward building scalable and secure apps, especially if you're working with distributed systems or want to integrate authentication via third-party providers like Google or Facebook.
What is OAuth2?
So, let's start simple. OAuth2 is a standard for authorization that allows apps to securely get access to resources (for example, user data) provided by other services. But before we dig into the details, let's briefly talk about the predecessor — OAuth1.
- OAuth1 was powerful but complex: it used HMAC-based cryptographic signatures and required more effort to implement.
- OAuth2 is simplified but still reliable. It relies on HTTPS for security and uses a flexible token concept.
Example
Imagine you want your app to post notes to Twitter on behalf of a user. Instead of asking for the user's password (and risking their security), you can use OAuth2. The user authorizes via Twitter, and your app gets a temporary key (a token) that lets it perform actions on behalf of the user. Convenient and secure!
Main players in the OAuth2 architecture
In any OAuth2 architecture you have the following players:
- Resource Server — the server where your data is stored. For example, this could be Twitter or GitHub.
- Client — your app that wants to access data on the resource server.
- Resource Owner — the owner of the data (for example, the user who authenticates).
- Authorization Server — the server responsible for issuing tokens after successful authorization.
Let's walk through an example:
- The user opens your app (the client).
- The app sends the user to the authorization server (for example, Google).
- The user enters their credentials (login, password) and gives consent for access.
- Google returns a token to your app so it can work with the user's resources (for example, contacts).
Think of it like giving your friend the key to your garage instead of handing over the key to your whole apartment!
OAuth2 flows: what they are and how they work
Depending on the use case, OAuth2 supports several "flows" or interaction patterns. Which flow you choose depends on who's requesting access and how it's done.
| Flow | Brief description |
|---|---|
| Authorization Code | Ideal for web apps. The client gets a token via the authorization server. |
| Implicit Flow | Deprecated and less secure. Used for SPAs where the token is returned directly to the client. |
| Resource Owner Password | The client asks the user directly for credentials (not recommended) |
| Client Credentials | Used by server-to-server apps that don't need a specific user's data |
Authorization Code Flow: an example
Let's dig into the Authorization Code Flow, since it's the most popular flow. It includes these steps:
- The client redirects the user to the authorization server.
- The user signs in and confirms the permission.
- The authorization server returns a temporary authorization code.
- The client sends that code back to the authorization server and receives an access token.
Diagram of this process:
[User] ---> [Client] ---> [Authorization Server]
^ |
|---------------------------------------------|
Token
Why is this secure? Because the token is issued via the authorization server, not handed directly to the client.
Why OAuth2 matters for microservices
Microservices are a whole chapter in app development. You might have dozens (or hundreds) of small services that need to interact securely. OAuth2 solves a lot of problems:
- Centralized authentication. For example, each microservice doesn't need to check logins and passwords itself.
- Access management. Microservices can focus on business logic while leaving security to a centralized server.
- Tokens. Every interaction is backed by tokens, which helps prevent unauthorized access.
OAuth2 use cases in real apps
Now let's get inspired by some real-world OAuth2 use cases.
- Google Drive API: You can access a user's files via their API using OAuth2.
- GitHub API: By authenticating via GitHub, you can manage a user's repositories.
- Slack API: Your apps can post messages in Slack on behalf of a user.
Each of these APIs uses the OAuth2 standard, which makes them secure and easy to integrate.
Common questions about OAuth2
What's the difference between OAuth2 and OAuth1?
OAuth2 is much easier to implement because it drops the complex cryptographic signatures (HMAC). Instead, everything is based on HTTPS, which already provides encryption.
Can I use OAuth2 for mobile apps?
Yes, OAuth2 works for any type of app, including mobile. For mobile apps people often use the Authorization Code flow or the Implicit Flow.
Problems with OAuth2 and how they get solved
While OAuth2 is a powerful tool, it has its issues. For example, what if an access token expires? Or what if it's stolen? That's where extra mechanisms like Refresh tokens come in (we'll cover them in upcoming lectures).
Also remember overall: only HTTPS! OAuth2 is effective only when used with a secure transport protocol.
Get ready for hands-on! In the next lectures we'll start implementing OAuth2 and JWT in our app. Time to learn how to protect your microservices not just from users, but from evil forces (oops, I mean attackers)!
GO TO FULL VERSION