Authorization with Facebook and Google
|

Conquer Authentication with Ktor: Part 7 – Introducing OAuth 2.0

ByTomas Zezula

In our previous post, we wrapped up the discussion on Json Web Tokens. We’ve come far in this tutorial, gradually uncovering more complex and practical use cases. Now, we’re turning our attention to a widely adopted authorization protocol – Open Authorization 2.0. While JWT primarily ensures secure communication, OAuth focuses on the delegation of access. Today, we’ll have a closer look at key concepts of this authorization protocol.

Table of Contents

Since we will be using similar terminology, let’s differentiate OAuth 2.0 from what we’ve learned about JWT. First of all, let’s get clarity on what OAuth actually means.

OAuth vs OAuth 2.0 – Does It Matter?

The short answer is yes, it absolutely does. Both OAuth 1.x and 2.0 versions are driven by the very same ambition – to establish a safe standard for users to authenticate without revealing their credentials to third party systems and applications. However, OAuth 2.0 surpasses the original version by making the protocol easier to adopt in practice.

Here is what you should know if you’re considering an upgrade to OAuth 2.0 from the legacy version or wonder about the major differences between the two.

  • Design overhaul. OAuth 2.0 is a complete rewrite of OAuth 1.0 from the ground up, sharing only overall goals and user experience.
  • Mutually incompatible. OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1.
  • Implementation complexity. OAuth 2.0 is generally considered easier to implement due to its simplified use of signatures. This is a key differentiating factor.
  • Security guarantees. Ease of implementation comes at a cost of security trade-offs. OAuth 2.0 revolves around bearer tokens which caters for an easy integration. On the other hand, these tokens can be stolen or compromised.
  • Clear separation of concerns. OAuth 2.0 supports non-browser implementations and provides a clear separation of resource delivery and authorization.

If you want to know more details, I highly recommend reading What’s the difference? OAuth 1.0 vs OAuth 2.0 by the Synopsis editorial team.

For the sake of conciseness I’ll further refer to OAuth 2.0 as simply OAuth.

Contrasting OAuth with JWT

You’ve spent time and effort learning about JWT and now you’re, rightfully so, asking yourself whether it was worthwhile. Given, most integrations lean heavily on OAuth.

While OAuth is a protocol for authorization and JWT serves as a standard for generating tokens, they often work hand-in-hand. Authorizing your service with a third-party OAuth provider is typically quite simple, as you depend on them to issue arbitrary tokens. At this stage, you don’t even need to know that JWT exists. That’s the beauty of OAuth – it makes authorization easily accessible to virtually anyone. However, the equation changes when you switch roles and become an OAuth provider yourself. This is when you can leverage the capabilities of JWT, utilizing it to tackle the challenges of managing both access and refresh tokens efficiently.

Another benefit of JWT is that it stores all relevant information about the user. In other words, JWT makes authentication stateless which results in improved scalability.

How OAuth Works?

Imagine someone wants to use an online service. This service asks that person to create an account. The user can either register a separate account with this service or choose to log in using their existing Google or Facebook accounts, saving time and effort.

Assuming the user is already logged into their Facebook account, they click on “Log in with Facebook”. Next, they see a detailed list of the specific information Facebook will provide to the online service. This could include their first and last name, email, profile picture, etc., but it does not include sensitive information like the Facebook password.

If the user agrees to share this information, they confirm and voila! The user is now logged in to the online service without having to create a new account or share their Facebook password. They’ve used OAuth 2.0, which simplifies login and protects user credentials.

The reason why the online service can access user information through Facebook is because the service’s developers have registered it with Facebook. In doing so, they established a verified connection and received a unique identifier for the service. We’ll explore this process in more detail in the next section.

Authorization Flow

OAuth 2.0 is an authorization framework that enables third-party applications to access a user’s resources on another service or platform without sharing their credentials. The process involves various components, including the user (resource owner), the third-party application (client), the platform hosting the resources (resource server), and the authorization server.

OAuth 2.0 supports several authorization flows (grant types), but the most common one is the Authorization Code Grant flow. Here’s a step-by-step explanation of how it works:

OAuth 2.0 makes a clear distinction between different responsibilities.

Initiating Authorization

  1. User initiates the authorization process. The user (resource owner) starts the process by clicking on a login button or a link on the third-party application (client) website or app. Please note that the client has no knowledge about the user.
  2. Client redirects the user to the authorization server. The client redirects the user to the authorization endpoint residing on the authorization server. This is usually a webpage where the user can grant permission. The URL includes query parameters like the client ID, requested scopes (access level), and a redirect URI (where the user will be redirected after authorization is granted).

User Authentication and Granting of Permissions

  1. Authorization server handles authentication. The authorizaton server asks the user for authentication credentials if not already logged in.
  2. Authorization server asks for permission. Once the user is logged in, the authorization server presents the user with the requested permissions for the third-party application.
  3. User grants permission. The user authorizes the requested permissions (scopes).

Exchanging Authorization Code for Access Token

  1. Authorization server returns an authorization code: Once the user grants the requested permissions, the authorization server redirects the user back to the client’s specified redirect URL, including an authorization code as a query parameter.
  2. Client requests an access token: The third-party application sends a request to the authorization server’s token endpoint with the received authorization code, client ID, client secret (if applicable), and redirect URL.
  3. Authorization server issues the access token: The authorization server verifies the received information and sends a response containing an access token (and optionally a refresh token) for the third-party application to access the user’s resources.

Accessing User Resources

  1. Client accesses the user’s resources: With the access token, the third-party application can now request the user’s resources from the resource server (API) within the authorized scopes. The access token is included in the Authorization header of each API request.
  2. Resource server validates the access token: The resource server checks if the access token provided by the client is valid (usually by calling the authorization server or by validating a JWT access token locally).
  3. Resource server returns the requested resources: If the access token is valid, the resource server returns the requested resources to the third-party application (client).

This flow provides a secure way to authorize third-party applications to access a user’s resources without sharing their credentials.

Terminology

In OAuth 2.0, there are typically four key roles, or parties involved.

  1. Resource Owner. This is typically the end-user who owns the data or capabilities being accessed.
  2. Client. This is the application requesting to access the resource owner’s account information or functionality.
  3. Resource Server. This server hosts the protected user accounts, it’s essentially the API you’re seeking to access.
  4. Authorization Server. This is what issues access tokens to clients on behalf of the resource owner, upon the owner’s approval.

Each role plays an integral part in a successful authorization flow. The Client is the app that wants to access the user’s account. As part of the process, the user (Resource Owner) must give the application (Client) permission to do this. This kick starts the authorization process. If all goes well, the application requests an access token (piece of data proving a permission was granted), which is issued by the Authorization Server. With the access token, the app can finally request information from the API (Resource Server).

Summary

OAuth 2.0 is an authorization framework that enables a third-party application to access a user’s resources on another platform without accessing the user’s credentials. The common authorization flow involves the user initiating the process, the application requesting access, and the authorization server granting an access token or a pair of access and refresh tokens.

Stay tuned for our next episode where we implement OAuth 2.0 with Ktor and Google.

Similar Posts

Featured image
| |

Streamlining Console Output Verification with Kotest

ByTomas Zezula

Console logging is often perceived as a bad practice, but in specific contexts, it’s quite suitable. Consider a scenario of a workshop where printing output directly to the console enhances transparency and simplifies the project setup. Using a comprehensive logger could lead to unnecessary clutter. However, there’s a downside to directly printing to the console—it makes it challenging to verify the result. Well, at least so I thought until I accidentally stumbled upon this awesome article by Thijs Kaper. Although Spring Boot provides out-of-the-box support for output verification, it’s also possible, and sometimes preferable, to implement it independently. In this blog post, I’ll demonstrate how to create a custom spec in Kotest that you can leverage in your tests. This spec automatically captures console output and provides the result for verification.

Code coverage abstraction
| |

Unlocking Test Coverage in Kotlin Multiplatform with JaCoCo and GitHub Actions – Part 1

ByTomas Zezula

Kotlin Multiplatform unlocks new possibilities for developing cross-platform applications. However, this innovative approach does not come without its complexities. Especially when delving into its specific Gradle configuration. One of the challenges is establishing a reliable, automated test coverage report – an integral part of maintaining code quality and integrity. In this mini-series, we’ll learn how to leverage JaCoCo Gradle plugin to generate code coverage reports. Additionally, we’ll leverage GitHub Actions to generate a coverage badge independently from any third-party platform. This approach simplifies the process by keeping everything within the GitHub ecosystem, providing a seamless workflow for your multi platform projects.

RAG with SpringAI
| |

Retrieval Augmented Generation with Spring AI

ByTomas Zezula

In our last post, we looked at enriching the OpenAI model with custom data through function calls. While this technique is useful, it has its limitations and performance trade-offs. Today, we explore a more efficient way of incorporating relevant data into prompts to receive accurate and relevant model responses. Retrieval Augmented Generation, or RAG, relies on preprocessed data that is readily available upon request. In this post, we will build an Extract, Transform, Load (ETL) pipeline that stores a large corpus of weather forecasts and learn how to efficiently retrieve relevant information from a vector store.

Failed Gradle build
| |

Gradle Multi-Module Builds: Setting Up Shared Dependencies

ByTomas Zezula

When you are managing a multi-module Gradle project, more often than not you’d want to share certain dependencies across different modules. This is particularly true for test dependencies. You can achieve this by defining common dependencies in the root build file and applying them to all subprojects. However, a problem often encountered is the dreaded Unresolved reference: testImplementation error. This blog post suggests a simple trick that resolves the issue. Give it a go and happy testing ever after!