12 posts tagged with "open_source"

Exploring Keycloak as an Alternative to WorkOS for Authentication Solutions

Keycloak and WorkOS are both identity and access management (IAM) solutions that offer various features for authentication, authorization, and user management. While they serve similar purposes, there are key differences between the two platforms that make them unique and suitable for different use cases. Keycloak is an open source platform under active development for over 8 years and known for its scalability and customization options. WorkOS is a closed-source platform that can quickly integrate SSO to an application. In this blog post, we'll explore the key differences between Keycloak and WorkOS, focusing on factors such as cost of ownership, scalability, deployments, and maintenance.

An exciting new feature has been added to Phase Two Organizations Extension! Organizations now support shared Identity Providers (IdPs) for mapping multiple organizations to a single IDP. This feature is especially useful for organizations that have multiple organizations that need to share the same IDP.

Often asked for by customers, this feature will now allow organizations to share the same IDP across multiple organizations. This will allow for a more streamlined user experience and easier management of users across multiple organizations. Meaning that admins can still keep organizations logically separated, but support the same IdP for authentication and authorization. The primary use case for this is applications that support both Google social login and Google Workspace enterprise SSO login. Some of our customers had 100's of organizations that used Google Workspace SSO. This change allows you to use a single OIDC integration with Google, rather than configuring 100's of SAML integrations.

Configuration is fully supported in the Keycloak Admin UI, is up-to-date with the latest Keycloak version, and is fully tested. This feature is available now to any Phase Two hosted customers and can be adopted by anyone leveraging the Phase Two Keycloak Organization Extension.

Exploring Keycloak as an Alternative to Okta for Authentication Solutions​

In today's rapidly evolving digital landscape, securing and managing user identities has become more critical than ever. Organizations are faced with the challenge of choosing the right Identity and Access Management (IAM) solution that balances cost, ease of implementation, and robust feature sets. Two popular contenders in this space are Keycloak and Okta. Keycloak, an open-source solution developed by Red Hat, offers extensive customizability and a community-driven support model. On the other hand, Okta, a leading cloud-based IAM provider, promises quick deployment and comprehensive security features through its subscription-based service. In this blog post, we will delve into a detailed comparison of Keycloak and Okta, examining their costs, total cost of ownership, implementation processes, and the rich array of features and capabilities each brings to the table. Whether you're a small startup or a large enterprise, understanding these key differences will help you make an informed decision for your identity management needs.

Since we first released our (most) popular Keycloak extension, Keycloak Organizations (Orgs) and made it available as open source on Github, the Keycloak maintainers have decided to build into native organization support.

This begs the question? What is different between Keycloak's upcoming organizations feature and the Phase Two Organization Extension?

Exploring Keycloak as an Alternative to Auth0 for Authentication Solutions​

When it comes to implementing authentication and authorization in web applications, Auth0 and Keycloak are two prominent solutions that offer robust security features. While Auth0 is a popular choice for many developers due to its comprehensive, cloud-based platform, Keycloak presents a compelling alternative, especially in terms of cost and flexibility. This blog post will delve into how Keycloak stacks up against Auth0, focusing on cost of ownership, maintenance, and functionality.

Keeping your brand consistent across user touch-points is important to modern Saas companies. Just like customizing Login Pages, customizing your email templates is just as important. Keycloak has a number of templates which can be customized.

Keycloak starts out with simple text templates, but unless you like spending your days looking at Unix terminals, you probably prefer some color and images in your emails.

With many companies racing into the cloud, very little is written about the huge opportunity, and potential pitfalls of building software for on-prem and private cloud deployments. With the growing Kubernetes and CNCF ecosystems, the balance point to justify self-hosting is constantly shifting. This is great news for companies that must host data and applications inside the enterprise. For software vendors looking to serve this exploding market, authentication can be a blind spot.

A story, inspired by customer use cases:​

You’ve built a successful enterprise SaaS product, and your cloud offering has taken off. Recently, you’ve been getting inquiries from government agencies, large companies in regulated industries, and foreign companies – all of which have legal, compliance or regulatory requirements that prohibit them from using your product in the cloud.

Given the size of the opportunity, you’ve decided to go for it. Your team has packaged your application up as a set of Kubernetes manifests, making changes, replacing cloud services with open source alternatives, and even built out a runbook to help your devops peers at the customer operate it themselves.

The big day comes, and you’re installing at your first customer. You expect that there will be some minor bumps along the way, but their first question just flattens you: “How do we connect this to our in-house identity provider?” It was a question that was never on your radar, but now it’s the most important thing for the customer.

Like most SaaS companies, you’re probably either hand-rolling your authentication and user management using something like Passport.js, Devise, Django, etc., using some social login options, or using a cloud-only service like Auth0 or WorkOS. If you had implemented SAML, the most common protocol for just-in-time user provisioning with enterprise identity providers, you probably went for a basic approach. You wrongly assumed that user management and identity brokering would be easier for on-prem.

You throw some engineering and customer success resources at the problem, but quickly realize it’s not a scalable solution. The customer wants to map their groups, and manage access and authorization through their IdP. Just the overhead of connecting to every possible type of IdP, and supporting that for every customer, will eat up your margin before they start using your application.

In today's digital landscape, managing user identities and securing access to applications and services is paramount for businesses of all sizes. As the demand for robust identity and access management (IAM) solutions grows, so does the market, with various commercial options vying for attention. When we first started using Keycloak over 7 years ago, we were surprised that there was a relatively unknown, but completely open-source alternative to commercial offerings in the Identity and Access Management market.

Today we're making two announcements: A new, highly-requested feature, and the open sourcing of the extension at the same time. We've received a lot of requests from customers to implement "magic link" login functionality that would allow users to login to an application using a link sent to their email or over some other secure channel.

To that end, we've implemented two pathways for creating a magic link. One can be configured in the Authentication section of the admin UI by duplicating the Browser flow, and replacing the normal Username/Password/OTP forms with the Magic Link execution type This mechanism inserts a authenticator in the login flow that intercepts the email address and sends the magic link in an email to to the user.

We've also implemented a web service that allows you to create a magic link without necessarily sending an email. This will allow you to send the link through another channel. Specification for the new endpoint can be found in the Magic Link API Documentation.

Both methods have the option of forcing the creation of a new user when an unknown email address is used. This allows a combination login/registration flow that combines an email verification. We think this really nails reducing friction in a new user flow.

We're open sourcing the Keycloak extensionsso that the broad Keycloak community can benefit right away. We are doing this in line with our commitment to keeping our core extensions open source. We hope you find these extensions valuable, and we look forward to feedback and participation from both our customers and the wider Keycloak community.

The extension is available on GitHub https://github.com/p2-inc/keycloak-magic-link

Today we're open sourcing a set of Keycloak extensions, specifically our Organizations extension, that are focused on solving several of the common use cases of multi-tenant, SaaS applications that Keycloak does not solve out of the box. We are doing this in line with our commitment to keeping our core extensions open source. These extensions are the basis of our Organizations features, which allow Phase Two customers to model their own customers in their systems and create enterprise "team" functionality that suits their business case.

A variation of this code has been built, enhanced and used in production by several customers for almost two years. It is now available as open source for members of the broader Keycloak community. We hope you find these extensions valuable, and we look forward to feedback and participation from both our customers and the wider Keycloak community.

The extension is available on GitHub https://github.com/p2-inc/keycloak-orgs