Guide

Ory & Supabase Url Shortener: Moving to the Ory Network

A
Andrew Minkin

Ory's blog has two blog posts about building a URL shortener using Ory Products and Supabase Database. Part 1 covers backend infrastructure and uses Ory Kratos and Oathkeeper. Part 2 covers a frontend part of the application. In this post, I will talk about moving from self-hosted to the Ory Network for the project, and we will discuss a path of migration to the Ory Network.

Why move to the cloud?

When I was building this demo project, I started from the 0.8 version of Ory Kratos, and once I finished, the 0.9 version was released. I needed to make minor changes to the configuration, such as changing whitelist_return_urls to allowed_return_urls. That's usually not a big deal. Still, teams must upgrade their dependencies time-to-time to prevent security issues and have more features.

The URL shortener project is a demo project and not deployed to any cloud environment, and using the Ory Network can be an overengineering and premature optimization. However, since I decided to deploy the service somewhere, I don't want to deal with the following things on production for Ory Kratos:

  1. Handle breaking changes for the configuration
  2. Upgrading version of Ory Kratos
  3. Running database migrations
  4. Updating the code not to use deprecated API endpoints

Hence, using the Ory Network seems a good idea because I can have decreased time-to-market and don't worry about upgrading versions of Ory Kratos, especially after the 0.8 release the Ory Network and Ory Kratos have 1:1 compatibility of APIs.

Let's start moving to the cloud, huh?

What services become obsolete after migration? Right now, the app uses the following containers:

  1. kratos to run Ory Kratos.
  2. kratos-migrate to run migrations against the database.
  3. mailslurper to read sent emails for development purposes.
  4. postgres-kratos to store identity data for Ory Kratos.
  5. kratos-selfservice-ui-node to serve a user interface for login/signup/recovery flows.
  6. oathkeeper that serves as an identity and access proxy for the project..

After the migration to the cloud, we don't need them anymore.

Moving to the Ory Network

As a prerequisite, I needed to create an Ory Network project, and I followed the documentation. In addition, I needed to install an Ory CLI tool. Once I had them installed, I came up with the following migration plan.

  1. Oathkeeper usage overcomplicates the app. I need to deploy it somewhere near the app, and I have only a couple of rules enabled. I can replace it with a small middleware.
  2. I don't need Ory Kratos anymore with self-service UI. Hence I need to test everything that would work with the Ory Network.
  3. I need to use the Ory proxy with the CLI installation for local development.
  4. Since I don't have any identities created, I can easily migrate without issues and write additional scripts to migrate the data.

Implementing an Ory Network middleware for the backend service. Let's replace the content of middleware/middleware.go with the following code

One can remove kratos, oathkeeper directories and the docker-compose.yml has the following content:

Run Ory Proxy

Ory Proxy is a reverse proxy deployed in front of your application. This allows the Ory endpoints to be mirrored on the same domain as the app you're running.

The Proxy rewrites cookies to match the domain your application is currently on. As a result, the origin of the cookies is set correctly to the domain you run the app on instead of <your-project-slug>.projects.oryapis.com.

This behavior is necessary to avoid issues with the browser CORS policy.

We'll use ory proxy to proxy traffic to the frontend application

ORY_SDK_URL=https://project-slug.projects.oryapis.com ory proxy http://127.0.0.1:3000

Configuring client application

Running everything together

docker-compose up -d
cd client
npm i
npm run dev

Open http://127.0.0.1:4000 and click Sign In or Sign Up buttons

Next steps

  1. Deploy frontend application to S3
  2. Deploy backend to AWS lambda
  3. Add Two Factor Authentication (2FA) to your App
  4. Add social signin features
  5. Configure more secure password policies
  6. Implement email and phone verification and account Activation
Never miss an article - Subscribe to our newsletter!
Back to blog