Today’s applications demand robust security. Gone are the days of simple username and password logins. Modern applications, especially those accessed from various devices, require a more sophisticated approach: OAuth 2.0 Authorization Flows. But what exactly are they, and when should you be concerned with them?
Whether you’re developing a mobile app, a server-side application, or a client-side application like a Single-Page Application (SPA), selecting the right authorization flow is crucial. This need is magnified by modern security demands, as both threats and regulatory requirements have become more complex.
Authorization flows define the process by which an application verifies a user’s identity and grants them access to specific resources. They become crucial when dealing with multiple applications and user accounts, ensuring only authorized users can access sensitive data.
Look at Neo below. He needs to verify if Trinity has send him any messages, but in order to do so, we must make sure he is the one really asking. Step 2 of the flow is what we will be focusing on today.
Current Authorization Flows
Here’s a breakdown of the most common OAuth 2.0 authorization flows, their uses, and which type of client they best fit:
| Authorization Flow | Description | Best Used For | Ideal Client Type |
|---|---|---|---|
| Authorization Code Flow | Involves redirecting the user to authenticate, then returning a code that is exchanged for an access token. | Secure access for web applications (SPAs) and server-side applications. | SPAs, server-side web apps |
| Implicit Flow | Directly returns tokens without an intermediate code exchange step. | Less used due to security concerns. Is now a legacy flow. | SPAs (beware of the possible vulnerabilties) |
| Authorization Code w/ PKCE | Enhances the Authorization Code flow with a secret verifier (PKCE) to secure public clients. | Securing public clients without client secrets. | SPAs, Mobile apps |
| Client Credentials Flow | Grants access tokens directly to applications themselves (not users) for machine-to-machine communication. | Accessing controlled resources within an app’s own backend. | Server-side applications |
| Device Code Flow | Used for devices that lack a browser or have limited input capability. | IoT devices, smart TVs, and other input-constrained devices. | IoT and constrained devices |
Choosing the Right Flow:
- For SPAs and mobile applications with user logins, the Authorization Code Flow with PKCE is recommended for its improved security over the standard Authorization Code Flow. This way, we don’t let an agent intercept Neo’s token when fetching for Trinity’s messages.
- The Implicit Grant Flow might seem simpler, but avoid it for sensitive applications due to exposed access tokens in URLs.
- Leverage the Client Credentials Flow for secure machine-to-machine communication. e.g. Take 2 apps not public facing needing to talk to each other while still needing to authorize access.
- Use the Device Flow for applications on devices with limited input methods, allowing users to confirm login on a separate device. See it as when your TV is asking you to input a code shown on your phone only.
Bad Practices with Authorization Flows
Since we tend to remember the negatives, let’s look at some bad practices to apply if we want to put Neo’s message’s app in danger of being intercepted by an Agent:
- Implicit Flow Usage: Given its susceptibility to access token leakage and lack of token authentication, this flow should not be used.
- Lax Token Storage: Storing tokens in local storage or other insecure locations makes them accessible to XSS attacks.
- Broad Scope Requests: Requesting more permissions than necessary can lead to overprivileged tokens, increasing the risk if they are leaked.
- Skipping HTTPS: Unencrypted communication allows attackers to intercept data, including tokens.
- Failing to validate tokens on the server-side: Malicious users could exploit vulnerabilities in client-side validation.
What About Keycloak?
Now you may be asking: Can I use these flows in Keycloak? Yes you can!
- Authorization Code Flow (with PKCE): Fully supported! Keycloak offers dedicated configuration options to enable the Authorization Code Flow and implement PKCE.
- Authorization Code Flow: Supported as well. However, for public clients (mobile apps, SPAs), it’s highly recommended to enable PKCE for improved security.
- Implicit Grant Flow: While Keycloak supports it, this flow exposes access tokens in the URL, making it less secure. Use it only for SPAs with limited security requirements.
- Client Credentials Flow: Fully supported. Keycloak allows configuring clients for machine-to-machine authentication using this flow.
- Device Flow: Supported by Keycloak, this flow is used for devices that either do not have a browser or have limited input capability, making them suitable for IoT devices and smart appliances.
By understanding the strengths and limitations of each authorization flow and adhering to best practices, you can secure their applications effectively against an evolving threat landscape. This guide not only helps in selecting the right flow but also in implementing it in a way that safeguards both user data and application integrity.
Only let the one look at his messages.
Stay tuned as we will uncover each flow in separate blog posts!