6 posts tagged with "identity provider"

📣 We are happy to announce that the first authentik Enterprise release is here! 🎉

The Enterprise release of authentik provides all of the functionality that we have spent years building in our open source product, plus dedicated support and account management. This Enterprise version is available in Preview mode in our latest release, 2023.8.

This is an exciting step for us, as we grow the team and the company and our user base. We officially became a company just last fall (I wrote about it in November 2022, in “The next step for authentik"), and this release is another move forwards in maturing authentik into the SSO and identity management app of choice.

One thing we want to acknowledge, up front, is that we would never have been able to achieve this goal without the years of support from our open source community. You all helped build authentik into what it is today, and that’s why all of our Enterprise-level features will be open core and source available, always.

There’s been a lot of discussion about licensing in the news, with Red Hat and now Hashicorp notably adjusting their licensing models to be more “business friendly,” and Codecov (proudly, and mistakenly) pronouncing they are now “open source.”

“Like the rest of them, they have redefined ‘Open’ as in ‘Open for business’”—jquast on Hacker News

This is a common tension when you’re building commercially on top of open source, so I wanted to share some reflections from my own experience of going from MIT, to GPL, back to MIT.

Identity – whether we’re talking about internal authentication (think Auth0) or external authentication (think Okta) – has become boring.

Little else proves this better than the fact that Okta and Auth0 are now the same company and that their primary competitor, Microsoft AD, survives based on bundling and momentum. Identity has become a commodity – a component you buy off the shelf, integrate, and ignore.

Of course, taking valuable things for granted isn’t always bad. We might regularly drive on roads we don’t think much about, for example, but that doesn’t make them any less valuable.

The danger with letting identity become boring is that we’re not engaging in the problem and we’re letting defaults drive the conversation rather than context-specific needs. We’re not engaging in the solution because we’re not encouraging a true buy vs. build discussion.

My pitch: Let’s make identity fun again. And in doing so, let’s think through a better way to decide whether to build or buy software.

In scenarios where security is offered as optional, there's an inherent risk. Customers, particularly those with a limited knowledge of digital security, might not fully comprehend its significance or choose to sidestep these features due to budget constraints. However, these seemingly inconsequential choices can expose users to significant risks. Without proper security measures in place, customers can become vulnerable to security breaches, putting their sensitive data at risk.

This situation raises a pressing question: how do we strike a balance in this landscape that is fair to both users and providers? Ensuring user convenience while maintaining robust security measures is complicated. If we lean too heavily towards convenience, we risk compromising on security. Conversely, an overemphasis on stringent security measures may lead to a complex and off-putting user experience.

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.