We recently gave a talk at the Keycloak DevDay 2024 conference in Frankfurt on our Organizations extension which provides single Realm multi-tenancy to Keycloak for modern SaaS applications. The hosts of the conference have posted the video of the talk on Youtube.
Take a look, and try it out today with our free hosted Keycloak instances that run all of our open source Keycloak extensions.
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.
Phase Two exposes an interface in the Admin UI to adjust the HTML and Text template. In the Styles > Emails tab, select a template to edit.
Enter the new HTML for the HTML template along with a matching Text template.
Using a test user, visit the flow of the templates you changed to have those emails sent to you and confirm you're happy with your changes.
The Attributes theme in our Phase Two deployment automatically make use of these themes. The sample template can be customized to fit your need. All you have to do is adjust the CSS colors and inject a link to your hosted logo file somewhere. There is a content section which you can copy/paste the default content from Keycloak into and customize. A simple HTML preview of the template lets you get an idea of how it will look.
Kaboom! Done. We challenge you to tell us the last time a change in Keycloak was that easy 💪
As always, our success is based on the success of our customers. We hope this extension and guide has helped you update the default Keycloak email branding to match that of your needs. If you have suggestions for further improvement of this feature, please reach out on GitHub!
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.
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.
The good news is that you’re not alone in missing this key enterprise need. Many companies who are new to on-prem and private cloud deployments learn this the hard way, many without losing customers.
However, the reality is that for an application that is used by an entire enterprise, who can use it (authentication) and how (authorization) is equally as important for on-prem applications as cloud. And, being hosted and operated by your customer, simplicity of management and transparency is more important than cloud.
Fortunately, there is feature complete identity and access management system that is equally at home both on-premise and in the cloud. It can easily facilitate identity brokering with the customer identity provider, as well as give their IT staff access to critical access and operational information.
At Phase Two, we’ve had a front row seat in solving this problem. Our customers have deployed Keycloak, bundled with their application to over 300 of their customer sites. In these deployments, Keycloak is used for identity brokering to the customer identity provider, SSO authentication for all of their deployed applications, and role and access management to broker and manage authorization within their applications.
In addition to solving these core challenges, Phase Two has built tools to extend enterprise use-cases and facilitate customer onboarding, one of the biggest drags on Customer Success hours, and ultimately a huge margin drain.
To this end, the most valuable tool, from our customers’ perspectives is our Identity Provider Setup Wizard. This tool is meant as a guide for customers’ initial IdP connection, turning an esoteric form into a clear step-by-step process for specific IDPs (what keys to get, where to store them, and so on). This had previously been the long pole in the onboarding tent. By giving the customers a tool to self-configure and manage their own IdP connection, Phase Two has gifted back valuable Customer Success hours and margin dollars.
We conveniently bundle all of these tools in Docker images for easy deployment.
Does the above story sound familiar, or something you might be stumbling into? Contact sales to find out how we can help your journey to on-prem be as painless as possible and supercharge your customer identity onboarding process.
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.
Companies such as Auth0, Okta, Microsoft (through AzureAD) had created cloud authentication services, and helped bring standardization to the market through implementation of standards, such as OIDC, SAML, SCIM, LDAP, etc. However, there was little differentiation among them, and despite their pricing models, were essentially commodities that were the same.
Amazon released AWS Cognito, which did price it as a commodity, but failed so miserably in UI and developer ergonomics, that it failed to reach a dominant market position despite its de minimis cost.
More recently, nascent companies such as WorkOS and Frontegg, while casting themselves as CIAM and “SSO made easy” to enterprise SaaS customers, are really just repackaging the same IAM features and protocol implementations that have been available in Keycloak for years. Furthermore, the pricing models have tilted back towards predatory on your company’s business model.
Amidst this landscape, open-source alternatives like Keycloak are emerging as powerful contenders, offering unique advantages over their commercial counterparts. Because the market has settled on standard protocols, it opened the door for superior open-source implementations to emerge with feature parity and standards compliance. Keycloak stands out as an alternative to commercial IAM solutions, enabling your business to unlock both flexibility and control.
So, given Keycloak's inherent advantages, while solving all of the same problems, why has it failed to receive broad market adoption? Looking back, and polling our customer base, it seems that Keycloak has suffered from a couple of barriers:
Obviously, we think that the barriers are something that can be solved, and Phase Two has been working hard in its open source extensions and cloud offerings to overcome these barriers. We've already made great strides, and believe that we're at the point where customers can realize the above advantages, while compromising relatively little -- All while achieving tremendous cost savings.
Already using one of the commercial systems? Keycloak is a complete, robust and mature identity solution that can replace your identity provider and user management systems today. It has complete parity with all of the major features of commercial IAM systems, and because of reliance on standards, migration is easier than you think. By migrating to Keycloak, you gain full control over your authentication and authorization processes, enabling seamless integration, customization, and scalability tailored to your organization's unique needs.
Phase two has implemented user migration support in the product for all tiers. This is meant to ease your transition from your existing user management system so that migration can occur incrementally with a complete fallback plan. For Premium and Enterprise subscribers, we include migration support. Contact sales to get started with your migration.
In a landscape dominated by commercial IAM solutions, Keycloak shines as a compelling alternative that combines the power of open source with enterprise-grade features and flexibility. With its cost-effectiveness, customization capabilities, deployment flexibility, and active community support, Keycloak empowers organizations to take control of their identity infrastructure, unlock new possibilities, and adapt to evolving security and compliance requirements. Whether you're a startup looking to bootstrap your identity management or an enterprise seeking to streamline operations, Keycloak offers a compelling solution that puts you in the driver's seat of your IAM journey.
Keycloak has been a leader in the Identity and Access Management (IAM) world since its launch almost 9 years ago. The market for IAM tools had several commercial offerings that failed to meet many business model and price needs, and Keycloak filled the hole with an open-source offering.
Fast-forward to today, Keycloak still leads with mature protocol implementations, hardened security, and a reliable architecture that has been battle-tested for years, under the stewardship of the maintainers at Red Hat. Whether deploying an in-house identity provider, or a user management system for a SaaS offering, Keycloak is an obvious choice.
With time, customer needs have evolved to include greater resiliency, expanded database selection, deploying in multiple regions, and operating across clouds. Because of operational complexity and architectural barriers, the Keycloak team decided to embark on a project to build a new underlying storage architecture. While promising, the project has taken longer than expected, and has yet to produce a production-ready result.
One of the great aspects of open source, is that it allows anyone to participate. About 18 months ago, Phase Two decided to implement support for CockroachDB for the existing storage architecture in order to meet this growing customer demand.
Phase Two helps SaaS builders accelerate time-to-market and enterprise adoption with powerful SSO, identity and user management features. To that end, Phase Two has created an enhanced distribution of Keycloak that bundles several essential open source extensions for modern SaaS use cases. Phase Two supports hosted and on-premise customers for a variety of use cases.
We eagerly dove into the challenge of adding CockroachDB support, but we quickly encountered a few key issues:
Keycloak internally uses the Hibernate ORM framework, which generates the SQL for the database type selected (called a "dialect" by them). Fortunately for us, the Cockroach Labs team had already built a custom CockroachDB Hibernate dialect that we were able to use without modification.
The Liquibase library is used by Keycloak for tracking, managing, and applying database schema changes. However, the authors had not anticipated adding support for entirely new database types without making code changes. We had to add CRDB, the Hibernate dialect, and the correct JDBC driver classes to the code to enable first-class support.
We ported the migrations that were incompatible with CRDB. This was required because of a few SQL semantics that are not supported in CRDB the same way they are in PostgreSQL.
Because CRDB uses serializable isolation by default, it was incompatible with Keycloak's use of distributed ("XA") or two-phase commit ("JTA") transaction managers. However, because the use of these is not necessary outside of an environment where other applications are using the same resources, it was possible to disable them. The Keycloak team was helpful in adding some environment variables to disable these, as they had also seen other database use cases that required it.
It also wouldn't have been possible to complete the changes without tireless support from the Cockroach Labs engineering team. They patiently helped us understand how CRDB is different, wrote code examples and tests, and were never shy about giving us access to everyone in the organization, regardless of level and how busy they were.
A HUGE thank you to the whole Cockroach team!
About 12 months ago, we launched our self-service, free product, built on our CRDB port and running on Cockroach Labs' managed serverless product. Over that period, we've provided over 900 free deployments, without a single production incident for both CockroachDB serverless and Phase Two enhanced Keycloak.
Furthermore, we've built out a test system that we run prior to releasing new versions in order to ensure that there are no regressions compared to the main Keycloak distributions. We run that test system and several benchmarks prior to releasing each new version of our fork.
The Keycloak team had embarked on an ambitious project over 2 years ago to completely overhaul the storage architecture. The so-called "map store" was designed, among other things, to provide a basis for high-availability by replicating data with multiple data centers. However, after that time period, there was still a lot of uncertainty and risk involved in getting to the point where the store was production ready. Thus the team decided to drop the project. See the announcement.
That leaves Phase Two's CRDB support in a unique position, as it is the only version of Keycloak that will support Cockroach's multi-region database.
We get it! Here are a few links to help you jump-start your work:
Phase Two provides self-service deployments of Keycloak hosted on multiple clouds. Plans start with a free version for testing and small production use cases. Dedicated clusters are available for customers requiring an SLA, isolated resources, and the ability to grow into larger use cases.
The database tier for our shared and dedicated clusters uses the CockroachDB serverless service. Working with Cockroach Labs gives us the expertise and reliability of hosting thousands of customer clusters at a massive scale.
If you're more DIY, and you're planning to run everything yourself, the base distribution image that contains our changes to Keycloak to enable CockroachDB support is available in the Phase Two Keycloak CockroachDB docker repository. It's a drop-in replacement for Keycloak that doesn't require much configuration beyond the official guides. We generally release a version within 1-2 days of the official Keycloak release.
For the impatient, we've also put together a complete docker compose example that includes a single node CockroachDB instance. You can also modify the configuration to use your own CockroachDB dedicated or serverless database.
Because of the uncertainty around the direction of the Keycloak storage architecture, Phase two is committed to maintaining support for the "legacy store" and our port to CRDB for the long term.
Many of our on-premise, support customers with large use cases asked us to build out a solution for massive-scale, fault-tolerant, multi-region use cases. One of the great parts of building support for Keycloak's existing storage architecture for CRDB is that we've been able to explore use cases that were previously impossible using the standard Keycloak distribution. For use cases with these requirements, plus global proximity to users and regional failover, we built global clusters, backed by CRDB multi-region database, for which we are now in Beta.
We're excited to see what you build with Keycloak and CRDB!
We're excited today to announce the launch of our dedicated clusters offering. Our Phase Two enhanced Keycloak distribution is now available as a hosted, dedicated cluster in the region of your choice.
About 9 months ago, we launched our self-service, shared deployments, offering customers the ability to create Phase Two enhanced Keycloak realms on our shared clusters. Over that period, we've provided over 700 free realms for testing and small production use cases. Many of you have reached out to us asking about an SLA, isolated resources, and ability to grow into larger use cases. Based on your requests and feedback, we built out our dedicated cluster offering.
Phase Two helps SaaS builders accelerate time-to-market and enterprise adoption with powerful SSO, identity and user management features. To that end, Phase Two has created an enhanced distribution of Keycloak that bundles several essential open source extensions for modern SaaS use cases. We support hosted and on-prem customers for a variety of use cases.
Dedicated clusters allow us to provide compute, network and storage isolation for customer workloads, and to easily deploy in the region where customer's users are. With dedicated clusters, we can guarantee an SLA that meets customer's needs with no resource contention from other customers.
Furthermore, it allows us to support customer-provided domain names, and access to monitoring and management capabilities not available in the shared clusters.
We built out our dedicated cluster offering using the best-of-breed open source tools and managed services.
The core consists of Kubernetes clusters in each supported AWS and GCP region. New dedicated clusters are provisioned instantly using FluxCD, a continuous delivery solution that gives us the history and auditability of git. Monitoring and alerting is done using Prometheus, Grafana, and a suite of external services that give us a complete view of cluster health.
The database tier uses a managed CockroachDB service provided by Cockroach Labs. Phase Two is the only provider that is capable of hosting the current Keycloak distribution (the "legacy" store) using CockroachDB. Working with Cockroach Labs gives us the expertise and reliability from hosting thousands of customer clusters at massive scale.
Starting today, you'll be able to log into the updated dashboard, and create your dedicated cluster by selecting a region and setting up your billing information.
Following successful billing setup, you will be returned to the Dashboard while your Cluster is provisioned. Once provisioned, you'll be able to create up to 20 realms per cluster, using the same easy setup as you are used to in the shared deployment offering.
Most clusters will be provisioned within 30 minutes, but some requests may take up to 24 hours. Additionally, for payment types such as ACH or SEPA, cluster provisioning will begin following payment clearing (up to 4 days in some cases).
Plans start at $499US per month when paid annually. This provides a set of compute, network and storage resources that have been tested for common use cases for up to 20 realms and 1 million users. If your use case is uncommon or you plan to scale beyond that, our system is designed to scale up with your needs. Our plans scale linearly with resource demands beyond our minimums.
We will continue to support a robust Free tier.
Many of our on-prem, suppport customers with large use cases asked us to build out a solution for massive-scale, fault-tolerant, multi-region use cases. One of the great parts of building support for Keycloak's existing storage system for CockroacDB is that we've been able to explore use cases that were previously impossible using the standard Keycloak distribution, or required complex, error-prone configurations. For use cases with these requirements, plus global proximity to users and regional failover, we built global clusters, backed by CockroachDB multi-region database, for which we are now in beta.
These clusters provide a minimum of 3 global regions, with 3 instances of Phase Two enhanced Keycloak per region. Global server load balancing provides geographic region affinity and failover to connect your users with the closest, available instances.
There will be two price tiers for global clusters, depending on your use of our shared CockroachDB clusters, or your own dedicated clusters. We expect to launch general availability of global clusters later in Q3 2023.
Please contact sales@phasetwo.io to talk to us about your global cluster use case.
Brand is important to modern SaaS companies, and nowhere is that more apparent than at the front door: the login experience. Unfortunately, the default design of the Keycloak login experience has a "face only a mother could love".
In order to allow customers to customize that experience, we've extended the default Keycloak theming functionality to allow you to easily customize the login pages from the admin console. This eliminates the need to package and deploy a custom theme, and allows fast iteration without restart.
If you're in a hurry, logo and color customization can be achieved by adding your logo's URL and three color choices. These are available in the General and Login tabs of the Styles section.
In order for these setting to take effect, your Realm Settings Themes must also be set to Attributes for the Login theme type
Many of you will have more stringent branding requirements. For this, you can override the styles of the default Keycloak login theme. To discover the base styles that are available using this theme, we recommend
Note that using CSS overrides will cause the colors from simple customization not to work.
In order to load your CSS, paste it into the "CSS" field in the Login tab of the Styles section.
This CSS will be the last CSS loaded, overridding the styles in the default keycloak login theme.
References:
keycloak login theme.To get you started with some ideas, we've created 3 example login themes that were done by overridding the CSS. These are free of license restriction, so feel free to download, use and customize the CSS at the links with the example images.
You'll notice that images, icons and fonts not found in the standard Keycloak themes are used. These are referenced by URL in the CSS. For example, if you are used to loading a custom font in the <head> of your HTML, it is possible to do it in CSS using @import:
@import url("https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700&family=Lexend+Deca:wght@300;400;500;600;700&family=Lexend:wght@300;400;500;600;700&family=Work+Sans:wght@300;400;500;600;700&display=swap");
And background and other images can be referenced by their full URL using url(...):
.login-pf body {
background-image: url("https://raw.githubusercontent.com/p2-inc/keycloak-themes/main/examples/saas/assets/SaaS%20BG.webp");
}
As always, our success is based on the success of our customers. We hope this extension and guide has helped you update the default Keycloak login branding to match that of your needs. If you have suggestions for further improvement of this feature, please reach out on GitHub!
We've received a lot of support requests about the right way to set up SSO connections. We've published a 5 minute video showing you how to do it easily. Also, the script is included below in case you miss anything!
Developers have been asking for concise setup instructions for SSO. You’re here for our enterprise SSO functionality. We hear you. Here’s a quick live setup to show you how easy it is.
I’m assuming you have already created a self-serve deployment.
We’ll use the identity provider wizard to setup a SSO connection to Azure AD. I’ve sped this up a bit, but you’ll get an idea of what is happening. Depending on your setup and target identity provider, this will be different.
Now let’s secure an application and use our new SSO connection to log in. For this purpose, we’ve got a debugging application on Github you can use to quickly see how a front end application is secured and what data is shared between Phase Two and the application.
frontend folder in your favorite editor or IDE.frontend. This will be a public OIDC client, with localhost:3001 as the root and redirect uri.keycloak.json from the configuration and copy it. Paste it into keycloak.json to configure your debug-app.Before we continue, we need to configure an authentication flow that does our SSO redirect.
Go back to the debug-app, and let’s try a login using an email domain that matches the one we configured.
npm i and npm start to start the debug app, and navigate to http://localhost:3001 in your browser. See that it redirects to the default login.debug-app.As a bonus, let’s map some information about the user’s organization memberships into the token in case we need to do something with that information in our application.
Now let’s go back to the debug-app and reload.
You now have a fully working authentication and enterprise SSO setup for your application. It took about 5 minutes!
There are a lot of guides out there, official and unofficial, for how to secure applications with Keycloak. The subject is rather broad, so it's difficult to know where to start. To begin, we'll be focusing on Keycloak's use of OpenID Connect (OIDC), and how to use that standard, along with some helpful libraries, to secure a simple but instructive application.
For the purposes of the sample, we'll actually be using two common applications, a frontend single-page application (SPA) written in JavaScript, and a backend REST API written for Node.js. The language we selected for the sample is JavaScript, but the principles apply no matter the implementation technology you choose.
When learning about identity and access management technologies, you'll be confronted with an alphabet-soup of acronyms to learn. OIDC, or OpenID Connect is one of the most important ones for securing applications, be it browser-based, APIs, mobile or native. Our friend over at OneLogin does a great job of explaining OIDC in plain english for those that are curious.
For the purpose of this guide, it is sufficient to know that OIDC is an open authentication protocol that works on top of the OAuth 2.0 framework. OIDC allows individuals to use single sign-on (SSO) to access relying party sites using OpenID Providers (OPs), such as an email provider or social network, to authenticate their identities. It provides the application or service with information about the user, the context of their authentication, and access to their profile information.
A "flow" in OIDC terms is a mechanism of authenticating a user, and obtaning access tokens. The flow we'll be using in this guide is called the authorization code flow. Fortunately, the internals of the flow are not necessary to understand, as Keycloak handles the details for you.
However, it is useful to see what is going on in the login process, so that you understand your user's experience.
We'll make an assumption for this guide that you are using a cloud deployment of Phase Two enhanced Keycloak. If you haven't already set one up, go over to the self-service launch announcement for details. You may also use your own Keycloak setup, but that setup is beyond the scope of this article.
The sample applications are available in our demo repo on Github. Clone that repo to your local machine. You'll find the applications in the frontend and backend directory, and a set of supporting files for configuration and deployment.
git clone https://github.com/p2-inc/debug-app.git
cd debug-app
Every application that Keycloak protects is considered a Client. Log into your Keycloak realm, and click on Clients in the left navigation, and click Create client.
frontend as the Client ID and click Nexthttp://localhost:3001/* for Valid redirect URIs+ in Valid post logout redirect URIs+ in Web originsdebug-app repo you cloned under the frontend folder.
Before we run the application, we need to create a user to log in. Click on Users in the left navigation, and click Add user. You only need to give the user a username and click Create. Find the Credentials tab and click Set password to give the user a password.
Open two terminal windows and go to the directory of the repo you cloned in both. To start, run the following commands in each terminal:
Frontend:
cd frontend/
npm install
npm start
Backend:
cd backend/
npm install
KC_REALM=<your-realm-name> KC_URL=<your-keycloak-url> npm start
Be sure to replace the realm name, and the URL of your Keycloak installation (e.g. https://usw2.auth.ac/auth/).
This will install the necessary components using npm, and will start the servers for both applications. Note: the applications use ports 3001 and 3002 by default. If you have other applications running on these ports, you may have to temporarily shut them down.
Load http://localhost:3001/ in your browser. This will load the frontend application, which will be immediately redirected to the Keycloak login page. Log in with the user you created.
Once you log in, you'll see your profile, and several menu items. First click to the Access token menu item. You'll see the information from the parsed access token that was returned by Keycloak. This contains information about the user, but also claims related to the users roles and groups. This is because access tokens are meant to be read and validated by resource servers (i.e. our backend service).
Next, click ID token. You'll see similar information to what we saw in the access token, but limited to a standardized set of information that identifies the authentication state of the user. ID tokens are not meant for calling resource servers, and because of that, don't contain claims that are meant to be validated by backend services.
Clicking Service will call the backend service. You'll see a message that indicates the frontend called the backend, passing the access token, and was authorized to access a secured service.
You can also try the built-in Keycloak Account Management console by clicking Account, which gives the user a simple way to manage their information that is stored in Keycloak. It is not necessary to use this with your applications, as you may choose to build it in to your app. However, it's a good tool to have out of the box.
Finally, clicking Logout will take you back to the login page. This is actually sending you to the frontend's initial page, which is redirecting you to the login page as its default behavior.
There's a lot that goes into implementation of the OIDC flow we used to secure our sample applications. Part of the reason to use Keycloak is the mature implementation and client libraries that make protecting applications in a secure way almost trivial.
We encourage you to look at the source in the sample applications (specifically frontend/app.js and backend/app.js) and observe how the Keycloak client libraries are used to secure these applications. This will be a good place to start when you are working on securing your own applications.
Another incredible advantage to using standards like OIDC is that you are not constrained to using Keycloak libraries. Because your applications may not be written in JavaScript also, it's easy to use other language OIDC client libraries. We maintain a list of OIDC libraries, and the OpenID Foundation also maintains lists of certified and uncertified implementations
Today you saw how to quickly secure an application using Keycloak, and learned more about the underlying OIDC standards. We look forward to seeing what you build!
Someone who is reading this article is probably very different that the average internet user when it comes to passwords. Developers and IT admins, either because of security savvy or compliance, use password managers, multi-factor authentication (MFA) mechanisms, or prefer sites that offer password-less authentication. Furthermore, they are keenly aware of the weaknesses in their personal "attack surface", and search for ways to balance convenience with risk.
But you are here because you want to find a way to implement magic links quickly. First, some background.
Magic links are a type of password-less authentication that allow your users to log in to your application following a link that is emailed to them, rather than typing a username and password. Magic links can also be used as a part of a multi-factor authentication (MFA) strategy.
In a magic link flow, the application's authentication provider asks users for an email address rather than a password. The authentication provider generates a link with an embedded token, and sends to the user's email. There may be some other steps taken by the provider, such as verifying the provided email address matches an existing user. The user then opens the email, clicks the link, is verified by the authentication provider, and is granted access to the application
Like any mechanism that tries to streamline a security process such as authentication, there are both pros and cons to the magic link approach. First in the plus column:
Nothing is perfect, and there are also several potential downsides to magic links:
Fortunately, there are things your application and the user can do in order to limit some of the possible downside risks of using magic links. Your application can:
Your user can:
Sorry for the wait! We wanted to give you an overview of magic links before diving into how to set them up with Phase Two.
If you haven't already, get an account on Phase Two. You'll notice that we use magic links in addition to social login options. As we said above, we're trying to make it as frictionless as possible to get in and start using the product.
Once you log in and create your first deployment, open the Phase Two enhanced Keycloak console. In order to email links to your users, you'll need to set up email. If you haven't already done that, head over to our email setup guide.
After you've completed email setup, select the Authentication menu item, and then select the Magic link flow from the list.
Open the configuration for the Magic Link Authenticator by clicking the gear icon on the last line with the Magic Link execution. You'll notice two options:
For the purpose of our demonstration, let's set Force create user to ON and Update profile on create to OFF (remember, low friction). Save the configuration, and go back to the flow page.
In the Action menu of the flow page, select Bind, and select Browser flow.
Now you're ready to test it out. If you don't have an application that is setup and protected by Keycloak, you can use the built-in account console to try it out. Navigate to the Clients menu, and open the link next to the account client in an incognito window (this will prevent conflict, as you are already logged in to the admin console as the administrator).
Click Sign In and you'll be redirected to the authentication page. Enter your email address, and you'll be sent a magic link. Click on the link in your email, and you'll see your details in the account console.
Go back to the admin console in the other browser window, and navigate to the Users section. You will be able to find the user that was just created.
Magic links are a great way to streamline your user onboarding and experience to help you easily drive engagement across your application. Phase Two makes it quick and easy to integrate magic links (and social login, and enterprise SSO, and much more). Stay tuned for more guides that will help you build the authentication experience that is right for your app.