29 posts tagged with "SSO"

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.

In today's digital landscape, businesses of all sizes increasingly rely on Software as a Service (SaaS) to streamline their operations and improve overall efficiency. However, as the adoption of SaaS applications continues to rise, so too do the security risks associated with these platforms. This has led to a growing demand for robust enterprise security features and Single Sign-On (SSO) solutions that can effectively safeguard sensitive data and protect businesses from cyber threats. In this blog, we'll delve into the intricacies of enterprise security, explore the benefits of SSO for businesses of all sizes, and examine the role of automation in ensuring robust security. We'll also discuss the importance of building SaaS apps with scalability in mind and highlight Authentik Security’s solution, authentik, as a unified authentication tool to help secure your organization.

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.

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.

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.

We all know standards matter, without them we wouldn't have the internet, we wouldn't have computers, and we wouldn't even have electricity. But standards are complex. They need to define edge cases, they need to be explicit but also allow room for implementations to advance and new features to be created. Today we'll dive into the OpenID Connect standard, why it can be challenging to implement and also what makes it, in some ways, easier than other standards.

“We made a mistake” – so said authentication provider Okta on March 25, 2022 – two months after an attack on one of Okta’s vendors (Sitel, a contact center) in January. During Okta’s initial investigation, the company didn’t warn its customers about the attack nor about its potential damage.

“At that time,” Okta admitted later, “We didn’t recognize that there was a risk to Okta and our customers.”

On March 22, three days before the admission, the group responsible for the attack – LAPSUS$ – shared screenshots online that evidenced the success of their attack. As users, customers, and onlookers reacted, Okta co-founder and CEO Todd McKinnon tweeted about the attack, claiming that the attack was “investigated and contained” but, more controversially, framing the attack as “an attempt.”