In today's digital world, security is a critical aspect of any organization's operations. While some may perceive security as an enterprise-level feature, it is essential for businesses of all sizes to prioritize and implement robust security measures. One of the most common security measures is to implement Single Sign-On (SSO), a digital authentication method that uses a single set of credentials to access multiple applications.

When building apps with scale in mind, the fundamentals involve designing and developing applications in a way that allows them to handle increased user demand, larger data volumes, and growing functionality without compromising performance or stability. Scaling an application effectively requires careful planning, architecture design, and the use of scalable technologies. This blog will explore some key considerations and strategies for building apps for scalability.

We are thrilled to announce the first ever Authentik Security hackathon! The event will be online, over the course of a week in summer of 2023. More details about the exact days, registration form, and agenda are coming soon.

Yes, there will be swag and prizes and accolades, possibly even low-key Git-fame.

More importantly than Git-fame, a hackathon gives us all (authentik employees and our amazing community) a chance to connect and collaborate and learn from one another as we work with the authentik code base and documentation.

The summer-time schedule for this first authentik hackathon comes about 9 months after we announced the formation of our new company, Authentik Security, back in November 2022 in the blog “Next steps for Authentik”. We think that getting together with our incredible community, and our still new-ish development team here at Authentik, is a great next step in our journey!

Face it, it is difficult to write about high tech, IT-based, computer-centric jobs without feeling that a bit of privilege exists in this space. Many of us in the software industry have employers who are sympathetic to, or even promote, the concept of “flex-time” and other enticing perks.

It is a major perk, even a luxury, to not have to clock in at a specific hour and then somehow miraculously wrap up your work and clock out in exactly eight hours. An act as simple as stopping at a pastry shop before work, or taking an extra long morning walk, without fretting about the exact minutes on your watch, is a privilege… but one that IT workers are increasingly insisted on having.

Back in 2018, I made a fateful decision: I chose to rebuild authentik using Lit and not React.

We like to think that technical decisions are primarily, well, technical, but some of the biggest consequences of these decisions come from how a technology is adopted and used – not the technology itself.

So it was with React.

In this post, I’ll explain why I made this decision, how it did and didn’t pay off, and why, ultimately, I don’t regret it. The point isn’t to sway you toward or away from React or to make an argument about web frameworks in general, but to encourage a discussion about the choices early-stage startups have to make.

None of us in the software industry are immune to the question:

How do we want to [re]define our repository structure?

Supply chains, whether for automotive parts or microprocessors, are complex, as we all know from recent history. Modern software, with more components than ever and automated package management, is also complex, and this complexity provides a rich environment for supply chain attacks. Supply chain attacks inject malicious code into an application via the building blocks of the application (for example, dependencies) in order to compromise the app in order to infect multiple users.

Even though JWTs (JSON Web Tokens, pronounced “jots”) have been around since 2010, it’s worth examining their more recent rise to become the dominant standard for managing authentication requests for application access.

When JWTs were first introduced, it was immediately clear that they were already an improvement on using a single string to represent the user information needed for authentication. The single string credential method was simple, but not as secure. There was no way to provide additional data or internal checks about the validity of the string or its issuer. With JWTs, there are expanded capabilities with more parts; there is a header, JSON-encoded payloads (called “claims”, which hold data about the user and about the token itself, such as an expiration date), and a signature (either a private key or a private/public key combination).

Let’s look a bit more closely at what a JWT is, review a short history of JWT evolutions and adoption, then discuss how JWTs are used in authentik.

In a blog from last November 2022, titled “Next steps for authentik”, I wrote about the launch of Authentik Security, our open core company built around the open source project authentik.

In this post, we’d like to provide updates on our progress in building out Authentik Security the company, ramping up the feature set in our open source identity provider, and taking the first steps in developing and offering an enterprise-level feature set for the Cloud or self-hosting. We are enthusiastic about our path forward and our plans to take authentik from a project to a product.

I started authentik in 2018 as an open source hobby project but in 2022, with help from Open Core Ventures, I started Authentik Security, an open core company built around the authentik project.

Building a new startup is, unsurprisingly, quite different from building and maintaining an open source project. With the arrival of funding and the requirement to build a business that could sustain itself now and scale as the company evolved, I had to confront some of the technical choices I made when building authentik – in particular, the choice to build authentik using Python and Django.

The primary reason behind choosing these languages was simple: I knew them well and could write code fast. In retrospect, we know now there was a tradeoff. I was able to code faster but the language itself would eventually impose speed limitations. Python isn’t the slowest language out there but when compared to Node.js and other compiled languages like Go, its speed can seem like a big problem. And Django on top of Python makes it even slower.

And yet, I stand by the decision and as the company has evolved, I think it was a good one. In this post, I’ll explain why this decision was a net positive, the benefits and costs of choosing these languages, and the lessons we learned along the way.