Why is Kinde built the way it is?

A while ago I wrote about open standards and why we value them so highly at Kinde. Open standards profoundly affect the way we build almost every part of our product, and go a long way towards making sure our customers, and their users, are as safe as possible.

In the world of authentication UI, there really are two distinct approaches, at almost entirely opposite ends of the spectrum: server-rendered and client-side architecture. Kinde is built server-rendered with fully hosted UI. The question a lot of people ask, is why, and why is this better? I thought it was worth going into some detail to help explain why server-rendered is a more secure approach to authentication.

In the early days of the internet, apps were 100% back-end. Then JavaScript came about and things began accelerating towards the client side.

Client-side development really took off with the introduction of client-side heavy libraries, and the ideas from those libraries gave birth to frameworks like React, Vue, and many more.

Recently however, things have started to swing back, and we see a return to server-side rendering with React server components, Next.js, Nuxt, and others.

This is an important shift in model and approach, and is highlighting the need for service providers to support both sides of the stack.

There are multiple reasons we started building Kinde with server-rendered UI first, but at their core they all come down to a set of key driving principles we followed when making architecture decisions:

When starting to build Kinde, we established a strict CSP policy, and then built functionality with this restriction applied from the get-go.

It’s very challenging to retrospectively add a restrictive CSP to your product. You need to start with a strict CSP first.

With the CSP in effect, it is impossible to execute a non-allowed script anywhere in Kinde admin or hosted UI, or to apply an inline style. As a side-effect, browser extensions that usually work by modifying the page with additional inline scripts or styles are blocked in Kinde.

There is a reason the OAuth 2.0 framework draws strict separation between public and confidential clients. You want your application to be server-rendered first to minimize attack vectors.

The most secure way of protecting user identities is with server-driven workflows. Hosted UI is the most effective way of achieving this.

💡 Kinde allows significant reduction in attack vectors compared to client-side authentication flows. You can opt-in to implement token exchange entirely in the back end without exposing tokens to the public at all.

As a developer, it’s important to manage the amount of risk you want to be responsible for. The more things you host in your product, the more responsibility you take on yourself. It is entirely possible to build a secure system on the client-side first but this moves critical security vulnerabilities to the client.

We chose to mitigate this risk. By building Kinde backend-first, we took responsibility for maintaining and improving the security posture on your behalf without any changes needed to your codebase.

Today Kinde supports deliberately limited customization. Each limitation is really a protection mechanism for our customers, although some we will, in time, be adapting to allow more flexibility. These will require other safeguards to make sure we retain the maximum protection:

• We don’t support uploading plain CSS because various exploits are associated with CSS. In time, we will expose safe CSS properties for extended customization.
• We don’t currently support headless authentication because making it work means relaxing numerous restrictions that are in place to keep the solution secure. But we are working on this and it’s coming soon.
• We are also working on a new feature which we call ‘faceless authentication’, a hybrid of headless and hosted authentication, allowing customizing and hosting the initial sign-in and sign-up pages. A middle step between fully hosted and fully headless that retains the security of hosted while allowing complete control over the ‘front door’ of authentication.

Kinde is an ever evolving platform, and everything we build adheres to smart security principles to make sure our customers are protected. We build everything secure by default and adopt the strictest approach from day one, and we mitigate risk by carrying the burden of security for our customers. We support our users to customize the platform and allow extension from this secure baseline, without ever reducing our highest levels of security.

Keep an eye on our release notes for up to date announcements as we release them.