You start off simple enough — username / password authentication in your application. Then, well, someone mentions that traditional passwords are a security vulnerability, so maybe we should use one-time passwords. That inevitably leads to discussions about magic links and multi-factor authentication. Next thing you know, one dev is in a corner, rocking back and forth and muttering something about SAML, and another dev just left — walked out the door, never to be seen again.

Well, not to worry, we've got just the tool for you.

authentik is an open-source identity provider written in Python. I'm going to focus on the self-hosted version, but they also offer a paid enterprise plan if you want some extra support.

The philosophy of open-source tools and self-hosting is a big, complex topic for another post. In the world of SaaS products, you likely don't need to self-host. I quite like hosted identity providers like Clerk and Auth0. They're good and appropriate solutions for different types of apps and companies.

But I just love to self-host tools. Tinkering and toying with Docker, reverse proxies, and sometimes even server hardware is a lot of fun to me. It does add complexity in some (or many) places, but a little extra complexity means you've got a little more control over your tooling.

Self-hosting also allows me to disconnect from the Internet and still be able to work on features and enhancements in my projects. As long as I've already installed the relevant packages or pulled the right Docker images, I can keep working if I'm in a place where I can't (or don't want to) connect to the Internet. This is a small thing, but really important to me.

authentik makes it really easy to self-host your application. Right out of the gates, they provide a Docker Compose example and a Kubernetes example. Getting authentik running took me about 10 minutes using the Docker Compose example. Most of that was reading. This can make authentik a great tool during the proof-of-concept or beta phase of your application, getting authentication out of the way so you can focus on building the cool and unique features of your app.

One of the great things that authentik has waiting for you is a bunch of documentation on integrating with a lot of tools you probably already use. These integrations range from other self-hosted apps like Outline (another favorite of mine) to cloud providers like AWS and even platforms like WordPress.

authentik's integration docs show you how to set up authentik for your existing providers and applications, so no need to dig around for the right configuration. Sure, if you're building your own application, you don't have the luxury of a README (until you write one, of course!), but don't worry — all the documentation you'll need for your choice of providers is at your fingertips. Personally, I'm fan of the OAuth2 provider for most my pet projects, but I also find the Proxy Provider to be a really great tool if you want to secure a static site that doesn't have any means of authenticating users.

This is a pretty nice default login screen, but maybe a mountain road isn't your vibe. You can change this background, add your own company logo, and add your own CSS. Just add your static files to your authentik deployment and modify to your heart's content.

But actually, that's not even the cool part of the customization to me.

authentik has the concepts of Flows and Stages that are used to determine what steps a user should take to log in, log out, and more. First, you define Stages that represent a single step of authentication — something like requiring a user to enter their username or a password. There's a whole lot to choose from. Once you've set up your Stages, you'll create a Flow, stringing those Stages together until you have a complete process to authenticate, register, or even delete a user. Flows can be imported and exported as .yaml files, making it easy to keep your Flows and Stages synced between different environments.

authentik comes with a pretty reasonable set of default Flows and Stages. If you're setting authentik up just to try it out, you might not need to add anything. They do have a couple of example Flows to get you started, though.

Flows and Stages can feel pretty intimidating. On your dev server, I'd recommend basically deleting all of the default Flows and Stages and building up new ones from scratch. It's the easiest way to learn how these pieces fit together. If you accidentally break something in dev, you can always just drop your database and spin up a fresh install.

authentik is an awesome tool and I've only scratched the surface of what it can do for you. As a self-hosted identity provider, it gives you a lot of control on how your services are authenticated. It's great for local development and beyond, and it has a lot of ready-to-go integrations for services you might already use.

If you're interested in further reading, I'd definitely recommend checking out the docs on Outposts and External Sources.

Hopefully this has given you some inspiration to spin up a local instance of authentik and try it out! It will definitely simplify your authentication needs.

So you're building a site and you've got a nice containing element around your content — but wait! Not all the content is the same width! That nice, neat tube of content is not so much a straight tube as a pile of different sized bricks.

It's a common layout problem, but how do we account for these 'breakout' widths in the layout? There's a couple ways we could go about it:

• Encapsulate each component and set widths and margins. (Works fine if you have full control but can be fiddly).
• Force the component out of the containing element with negative margins. (Works fine if there's only a little deviation).
• Use CSS Grid to build a fluid universal grid! (????).

That last one is what we'll be exploring: how to use CSS Grid definitions to allow for consistent component sizing across all breakpoints — no media queries required!

This is a technique that's based on Ryan Mulligan's 'Layout Breakouts' which is based on Josh Comeau's 'Full-Bleed Layout' and is especially useful when creating a fully fluid layout. This also pairs well with fluid type techniques resulting in layouts that TRULY scale with the viewport size.

Setting Up the Grid #

Here's the layout we're going to be building:

If we break apart the design, we've got 4 possible widths for components:

• Full-Width
• Feature
• Popout
• Content

We've also go some special side-anchored elements that 'stick' to one of the screen edges but also honor the other element widths. We'll come back to these later on.

Now that we've categorized the widths, lets start drawing column edges and defining areas:

1. Left margin / Full-Width
2. Left Feature
3. Left Popout
4. Center Content
5. Right Popout
6. Right Feature
7. Right margin / Full-Width

That's a lot of columns!

Yet on mobile, we only need 3 columns, just left margin (1), center content (4), and right margin (7). We want some of these intermediate columns to disappear!

Fortunately, CSS Grid gives us some powerful tools to create the measurements needed—yes, even for the disappearing columns! We won't even have to write any media queries for this one. We can make just ONE definition that works at all sizes.

We'll store our measurements as CSS variables for easy use later on:

Let's break these down.

--gap: clamp(1rem, 4vw, 2rem);

gap will be our side margin, allowing it to stretch up to 2rem at max, with a preferred width of 4vw, but never going below 1rem.

--full: minmax(var(--gap), 1fr);

We're going to use the minmax() function for these next three measurements to say: "If there's room in the CSS Grid, you can expand out to here but then don't go smaller than the minimum".

The full area is going to expand from left edge to right edge (remember we have to split the areas to allow for the other columns) and will double as our margin, so we'll pop in our gap value as our minimum and tell it that it can expand up to 1fr, or basically as much space as the rest of the grid will allow it.

--feature: minmax(0, 12vw);
--popout: minmax(0, 2rem);

The feature and popout both have a minimum value of 0. This is what powers our disappearing columns! As other areas of the grid expand, these will collapse when there's no longer any room for them, essentially taking up no space.

--content: min(clamp(30rem, 52vw, 60rem), 100% - var(--gap) * 2);

And then finally, our content area is our most complex measurement. It's saying, take the minimum value of either:

1. A fluid measurement that can be 30-60rem (with the help of clamp())
2. OR full width minus our gap value (but doubled for both left and right values).

These measurements can be changed to fit the needs of your layout. Specifically the feature and popout maximum values and the first content value. For example, our use of vw for the feature means it will fluidly expand out as the screen grows whereas the popout will remain only 2rem larger on each side than the content column.

Now we can assemble these measurements in a CSS grid column definition. We'll name our column edges with [custom-ident] and use the -start and -end endings to help make assignment easier later on.

The definition is complex, but if we visualize the start and end lines of our columns as well as the measurements, it looks like this:

You can see we have our middle content column, our disappearing feature and popout columns, and finally our full columns that double as our margin.

To finish off the definitions, we need to create column assignments. Because we named our columns with custom identifiers and specified the start and stop lines, we don't have to fiddle with grid numbers. We can assign them directly like:

And if we want to create a default assignment for elements in the grid (which is especially useful if you don't have full control over the markup) you can create one like this:

Now you can attach any of these classes to components in your grid and have them snap to the width you want.

Watch the screen capture below as the grid scales down. You can see the feature and popout columns disappearing as everything transitions to a mobile width, and then expands back up.

You can see a demo of the base setup here:

Nesting Grids #

Now let's go back to our header element. You can see that though the header is full-width, we actually want its inner content to honor the feature width.

Fortunately, because of the flexible nature of this grid definition, we can repeat the definition and then continue using the same column names on the inner structure. Because our grid only goes one layer deep we're free to replicate as much as we need or even break out and use different layout methods for the component interiors.

You can see it in action here:

Anchoring Left and Right #

Remember those side-anchored components? This is where we need to get a little tricky to line everything up.

Going back to our diagram, we want an element to span MOST of the way across the page, but end at the opposite feature edge. We can reuse our column definitions for the first part.

Great! That gives us exactly what we want... except for when we try to nest the grids.

Our original grid definition assumes that our content, while different widths, is centered in the window. We have to rethink our inner grid definition a little bit.

We're shaving off one end of the grid, specifically a full definition. So two things need to happen:

1. We need to adjust our content width to now account for only having one gap.
2. We need our new grid end to stop at the edge of the feature column.

We can achieve this with a new measurement and a new grid definition:

We've replaced the inner content measurement with the new value and combined the feature and full ends with the final line of the template column definition:

[feature-end full-end]

This will allow redefinition inside the new side-anchored component. You will notice that you'll need to supply your own padding for the inner as they no longer have that final margin to prevent it from reaching the new grid edge.

If you want to reverse this to be anchored to the right, you can flip the grid definition, moving the double start to the top like:

You can see a demo of the side-anchored component here:

But What About Tailwind! #

We love using Tailwind at Viget as a Team Accelerator™, and it's straightforward to implement these measurements and definitions in your Tailwind config.

Everything is effectively the same, but you'll call your grid classes like grid-cols-breakout to set the grid, and your columns like col-feature per Tailwind naming conventions.

Forwards to a Fluid Future! #

And there you have it! A media-query-less fluid breakout layout defined with CSS grid!

While the setup is more complicated at first glance, I've found that the more fluid your layout rules are, the FEWER rules you have to write overall! Especially when paired with fluid type, dynamic viewport units, and all the amazing features that are landing in CSS — it's truly a fluid future!