17 posts tagged with "keycloak"

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.

What are magic links?​

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

Pros and cons​

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:

• Enhances user experience, which makes users more likely to use your application, and be satisfied with the experience. This drives user engagement.
• User onboarding is accelerated, as magic links can be sent to new users as well as existing ones. Registration for your application is as easy as entering your email address.
• You'll never have a password breach. When there are no passwords, there are no password breaches. A huge number of corporate data breaches are due to insufficient and compromised passwords.
• No more customer support requests related to lost passwords. Over half of customer support requests are due to authentication problems, many of those are users unable to remember their passwords. This eliminates a huge portion of those.

Nothing is perfect, and there are also several potential downsides to magic links:

• Account security and access are now tied to the security of the user's email account. If the user's computer or other device is compromised, and attacker could potentially obtain the link and impersonate the user.
• If the user or email provider does not enforce encrypted network access to email, it may be possible for an attacker to perform a man-in-the-middle attack where they can obtain the link by observing network traffic.
• Ability to access your application is now tied to email deliverability. If your email service or the user's email provider fails to deliver the email containing the link in a timely fashion, it could deteriorate the experience for the user.

Limiting risk​

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:

• Make the magic links single use, or set a very short expiration time for the links.
• Enforce an additional factor when using magic links.

Your user can:

• Choose an email provider that enforces the use of encrypted connections.
• Use multi-factor authentication (MFA) mechanisms to further protect their email accounts.

Setup guide​

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:

• Force create user creates a new user when an email is provided that does not match an existing user. This allows the use of magic links to register new users that have not been previously seen.
• Update profile on create adds an UPDATE_PROFILE required action if the user was created. This means that the user will need to fill out other required fields such as first/last name, etc.

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.

One of the first things you will need to do when getting a Keycloak Realm ready for use is to set up your email server configuration. There are many system emails that are sent to users in the course of verifying and updating user accounts: Email address verification, magic links, password reset, account update, login failure notifications, identity provider linking, etc.

In order to provide your users with a positive experience, these messages need a way to get to them. Keycloak supports any internet reachable SMTP server. If you are currently testing, and don't have an email server or service that you currently use, SendGrid provides free accounts that allow you to send up to 100 emails per day forever. For debugging, you can also use a service like MailTrap to give you a catch-all for emails coming from Keycloak.

If you are using a Phase Two Deployment, log in to the self-service dashboard, and click on the Open Console link for the Deployment you wish to use. Once in the Keycloak admin console, click Realm settings in the left menu, and then click the Email tab.

In the first section, labeled Template, you will set options that will be used in the templates for the emails that are sent to your users. The only required field is the From field, which must contain the email address the user will see the email originating from. This should be an email address that your email server is expecting, and it will not block for authorization reasons.

The other fields in the Template section are not required, but will enhance how your emails look:

• From address used to send emails (required)
• From display name a user-friendly name displayed along From
• Reply to an email address that will be used by email clients when your user replies to an email
• Reply to display name a user-friendly name displayed along Reply to
• Envelope from Bounce Address used for the mails that are rejected

In the Connection & Authentication section, you will provide details of your SMTP server:

• Host indicates the SMTP server hostname used for sending emails
• Port indicates the SMTP server port (usually 25, 465, 587, or 2525)
• Encryption support encryption for communication with your SMTP server
• Authentication if your SMTP server requires authentication, and supply the Username and Password

Finally, before you click Save, click the Test connection button to send a test email to the email address of the currently logged in user. If you don't have that set, you might have click Save and edit your user before you come back. You'll receive a success message, or information that will help you resolve problems.

Once you do that, you'll have accomplished a significant task which enables lots of other functionality!

Also, stay tuned for another post on how to customize your email templates to match your branding and messaging.

We've been pretty quiet over the summer. Since we released the Organizations and Magic Link extensions and open sourced them, there has been a lot of interest in using Phase Two.

We were flattered by the inbound interest, but our small team wasn't able to keep up with demand for trial accounts. Rather than scramble against that demand, we opted to pause new accounts, and instead build a self-service tool to allow anyone to quickly provision a new deployment a try it out.

Today we're announcing the beta launch of the Phase Two Self-service deployment tool. This tool allows you to easily create new deployments of the Phase Two enhanced version of Keycloak in our secure, highly-available clusters. In the future, it will also allow you to deploy dedicated instances that use your own database.

Take a look at how easy it is to get started:

The clusters that run our deployments are available in two regions (AWS, us-west-2 and eu-central-1), and are backed by CockroachDB, giving you scale, resilience and low-latency performance. In the future, clusters and dedicated instances will be available in other regions based on demand.

We hope you find this new tool valuable, and we look forward to feedback and participation from both our customers and the wider Keycloak community.

TRY IT NOW!

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 committment 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 set of Keycloak extensions 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 committment 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

Per our committment to keeping our core extensions open source, today we're releasing our Keycloak extensions to the event system. These extensions form the basis of how our Audit Log features are built.

Additionally, we're providing several goodies that will be valuable to others building extensions on top of Keycloak, including a generic scriptable event listener, an event emitter to send events to any HTTP endpoint, a mechanism for retrieving event listener configurations from realm attributes, a mechanism for running multiple event listeners of the same type with different configurations, and a unified event model with facility for subscribing to webhooks.

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-events

Following the initial release of Phase Two's authentication and SSO tools 3 months ago, we had a warm reception by several early- to mid- stage SaaS companies. The message was consistent. SSO was a key barrier to unlocking enterprise customers, and we had made it much easier to quickly integrate the alphabet-soup of enterprise identity providers.

Furthermore, many of our customers have responded well to our "one price per project" idea, citing that competitors and other enterprise authentication companies had pricing models that ramped on a per-user and per-SSO connection basis, making them economically unattractive to companies with business and pricing models that couldn't support that.

One of the other points that we heard loud and clear from our first customers, was the fear of vendor lock-in. Integrating tools like this can be a large effort, and can be difficult to unwind if the terms or service fall short. While our adoption of standards such as OpenID and SAML allayed some of those fears, we wanted to go a step further.

We built the initial verison of Phase Two as a set of extensions to the Keycloak Open Source Identity and Access Management system, built and maintained by Red Hat. After several months of developing for it, and operating it for our customers, we've decided to continue using it. Keycloak has been battle-tested and hardened for over 6 years. It's security and reliability is depended on by organizations from small startups to Fortune 500 companies and governments.

To put to rest any future concerns about vendor lock-in, we're committing to making our core extensions to Keycloak open source. While we will endeavor to make Phase Two simple to use, operate and scale, we will maintain compatibility so that customers can migrate to their own Keycloak deployment. Updates and links to our open source extensions will be published in the Open Source section of the documentation, and will be available in our p2-inc GitHub organization page.

We have benefitted immensely from the open source communitiy, and we are excited to give back!