Keycloak - Inero Software - Software Consulting https://inero-software.com/category/keycloak/ We unleash innovations using cutting-edge technologies, modern design and AI Tue, 10 Feb 2026 11:48:41 +0000 en-GB hourly 1 https://wordpress.org/?v=6.9.1 https://inero-software.com/wp-content/uploads/2018/11/inero-logo-favicon.png Keycloak - Inero Software - Software Consulting https://inero-software.com/category/keycloak/ 32 32 153509928 Keycloak and SIEM Integration at Enterprise Scale https://inero-software.com/keycloak-and-siem-integration-at-enterprise-scale/ Tue, 10 Feb 2026 09:20:41 +0000 https://inero-software.com/?p=8507 KeyCloak is one of the most widely adopted enterprise identity and access management (IAM) platforms today. At Inero Software, we work with Keycloak on a daily basis — delivering Keycloak deployment, integration, and consulting services for organizations that rely on it as a core security component. In one of our…

Artykuł Keycloak and SIEM Integration at Enterprise Scale pochodzi z serwisu Inero Software - Software Consulting.

]]>

KeyCloak is one of the most widely adopted enterprise identity and access management (IAM) platforms today. At Inero Software, we work with Keycloak on a daily basis — delivering Keycloak deployment, integration, and consulting services for organizations that rely on it as a core security component.

In one of our recent production projects, Keycloak was integrated with a SIEM platform to provide full visibility into authentication and authorization events. Below, we share what this integration looks like in practice — and what really matters when Keycloak operates at enterprise scale.

SIEM as a natural extension of enterprise IAM

In large organizations, IAM is never an isolated system. Authentication and authorization are just one step in a much broader chain of business and security processes. That’s why enterprises rely on SIEM platforms such as Splunk to centralize and correlate events coming from multiple systems.

From our experience with Keycloak-based SSO architectures, IAM events are among the most valuable data points in SIEM pipelines. We previously described the foundations of such setups in our post on
hands-on Keycloak SSO – from setup to integration, where identity becomes a shared service across the organization.

Starting point: no ready-made Keycloak–SIEM integration

Although Keycloak offers extensive APIs and extension points, enterprise deployments often expose gaps that are invisible in smaller setups. In this case, the SIEM platform did not provide a maintained, production-ready connector for ingesting Keycloak events.

This is a pattern we frequently encounter during Keycloak enterprise integrations:
out-of-the-box features cover the IAM core well, but integration with security tooling often requires custom work. Similar limitations — and ways to address them — are discussed in our overview of Keycloak best practices for secure enterprise environments.

Keycloak clustering and consistent event delivery

As is typical for enterprise environments, Keycloak was deployed in a clustered configuration with multiple nodes handling authentication traffic. While events are generated across many instances, the SIEM system must receive a single, consistent security timeline.

Using Keycloak’s cluster-aware APIs, we implemented logic that:

    • coordinates event delivery across nodes,

    • ensures that scheduler tasks execute on the appropriate instance only,

    • avoids duplication or missing data.

This kind of orchestration is rarely mentioned in basic tutorials, but it becomes essential once Keycloak is part of a broader security ecosystem — something we often highlight when discussing enterprise-grade Keycloak operations.

Architectural alternatives for delivering Keycloak events to SIEM

While the core challenge remains the same — high event volume and the need for buffering and batching before delivery — there are two primary architectural approaches to integrating Keycloak with a SIEM system.

Application-level integration inside Keycloak

The first approach is to handle event collection, buffering, and delivery at the application level, directly within the Keycloak runtime. This can be implemented either as custom code or by leveraging existing Java libraries that provide built-in mechanisms for buffering, batching, and reliable event delivery.

Because Keycloak itself is Java-based, this model allows the integration to stay close to the IAM layer and offers fine-grained control over:

    • which events are collected,

    • how they are enriched or filtered,

    • when and in what form they are delivered to the SIEM.

The trade-off is ownership: this approach requires custom implementation, testing, and long-term maintenance, but in return provides maximum flexibility and visibility.

Platform-level integration using Kubernetes agents

The second approach moves the responsibility for event collection and delivery outside of the application, to the platform layer. In Kubernetes-based deployments, SIEM vendors such as Splunk provide dedicated agents that can collect and forward logs and events from applications running in the cluster.

In this model:

    • the application’s implementation language becomes irrelevant,

    • buffering, formatting, and delivery logic are handled by the agent,

    • operational effort is reduced by relying on vendor-supported tooling.

This comes at the cost of reduced control over event semantics and processing, but can significantly simplify integration in standardized Kubernetes environments.

In practice, the decision between these approaches comes down to a balance between control and implementation effort. Application-level integration offers maximum precision and flexibility, while platform-level integration prioritizes speed of delivery and operational simplicity — both valid choices depending on enterprise requirements and constraints.

What we take away from this deployment

Our key takeaway is simple: Keycloak scales extremely well in enterprise environments, but its real value emerges when it is thoughtfully integrated with surrounding security infrastructure.

SIEM integration is not an optional add-on — it is a natural extension of a mature IAM architecture. For organizations operating at scale, this is where Keycloak integration and deployment expertise makes a tangible difference.

At Inero, solutions like this are not experiments or proofs of concept — they are part of how we deliver production-ready IAM platforms for enterprise clients, building on real-world experience rather than documentation alone.

Artykuł Keycloak and SIEM Integration at Enterprise Scale pochodzi z serwisu Inero Software - Software Consulting.

]]> 8507 Keycloak Deployment Auditing – General Scope and Guidelines https://inero-software.com/keycloak-deployment-auditing-general-scope-and-guidelines/ Mon, 29 Dec 2025 10:08:56 +0000 https://inero-software.com/?p=8306 Keycloak Deployment Auditing – General Scope and Guidelines Practical lessons from auditing multi-realm, multi-client Keycloak environments in medium and large organizations  1. Introduction In medium and large enterprises, Keycloak deployments rarely follow a simple “one realm – one application” pattern. In reality, such environments typically consist of multiple realms reflecting…

Artykuł Keycloak Deployment Auditing – General Scope and Guidelines pochodzi z serwisu Inero Software - Software Consulting.

]]>

Keycloak Deployment Auditing – General Scope and Guidelines

Practical lessons from auditing multi-realm, multi-client Keycloak environments in medium and large organizations

 1. Introduction

In medium and large enterprises, Keycloak deployments rarely follow a simple “one realm – one application” pattern. In reality, such environments typically consist of multiple realms reflecting organizational structures, environments, or business domains, alongside dozens or even hundreds of client applications.

 

These clients often include web frontends, backend services, machine-to-machine integrations, and legacy systems, all maintained by different teams with varying levels of IAM expertise. As a result, Identity and Access Management quickly becomes a shared responsibility rather than a centrally controlled component.

“A Keycloak audit is not about verifying settings in the admin console — it is about understanding how identity, applications, and security decisions interact at scale.”

The primary goal of a Keycloak deployment audit is therefore not to “find flaws in Keycloak itself”, but to assess whether the entire authentication and authorization ecosystem is secure, coherent, and aligned with modern OAuth 2.1 and OpenID Connect best practices.

From our experience auditing complex enterprise IAM landscapes, a comprehensive Keycloak security audit focuses on three complementary objectives:

    • evaluating the configuration of the Keycloak Authorization Server,
    • reviewing how client applications integrate with Keycloak,
    • identifying security risks emerging from the interaction between both sides.

 

This holistic approach is essential, as many real-world security issues do not stem from a single misconfiguration, but from subtle inconsistencies across multiple realms, clients, and applications.

 

 

OVERALL RISK SEVERITY (ORS) MODEL

ORS

Impact

HIGH

Medium

High

Critical

MEDIUM

Low

Medium

High

LOW

Note

Low

Medium

 

LOW

MEDIUM

HIGH

 

Likelihood

 

 To prioritize findings in a meaningful and actionable way, audit results are typically classified using a risk-based approach inspired by OWASP methodologies. Each finding is evaluated as a combination of:

    •  likelihood of exploitation, 
    • potential impact on confidentiality, integrity, and availability.

 

This allows organizations to distinguish between:

    •  critical risks with immediate business impact, 
    • medium and low risks related to configuration hardening and attack surface reduction,
    •  best-practice recommendations aimed at long-term security maturity.

Keycloak-side audit – known patterns, real-world consequences

 

Configuration aspects of Keycloak itself are well documented and widely discussed in official  documentation and community guidelines. Nevertheless, real-world audits of large-scale deployments consistently reveal recurring issues such as:

    • lack of regular realm key rotation,
    • missing client secret rotation,
    • overly permissive redirect URIs and web origins,
    • unused but enabled service accounts,
    • globally enabled “full scope allowed” settings,
    • deprecated direct access grants left active,
    • missing or inconsistent enforcement of PKCE.

 

While these topics are well known, they are worth revisiting from an operational perspective. In large, multi-realm Keycloak deployments, even seemingly minor configuration oversights can accumulate and significantly increase the overall attack surface.

2. Client-side audit – where the highest risks emerge

From a security standpoint, the most sensitive and often underestimated part of a Keycloak deployment is the client application layer. Even a well-configured Authorization Server cannot compensate for insecure client-side implementations.

“In real-world Keycloak deployments, the most critical security risks rarely originate in the IAM platform itself — they emerge at the client application layer.”

In practice, the most severe findings during Keycloak audits are almost always related to how applications consume tokens, validate authentication state, and handle sensitive data after a successful login.

 
Missing token validation in client applications

One of the most critical issues observed in enterprise environments is incomplete or missing access token validation on the application side. This includes scenarios where:

    • endpoints do not verify authentication at all,
    • token signatures or claims are not fully validated,
    • authorization checks are inconsistently applied across APIs.

Such vulnerabilities effectively bypass Keycloak entirely, allowing attackers to interact directly with application endpoints without compromising the IAM platform itself.

 
Insecure token storage and handling

Another high-impact issue involves improper handling of access tokens within client applications. Common anti-patterns include:

    • storing tokens in cookies without Secure or HttpOnly flags,
    • persisting tokens in local or session storage,
    • sharing tokens across application components in a durable form.

In browser-based applications, these practices dramatically increase exposure to XSS attacks and session hijacking. From an architectural perspective, this is an application design flaw rather than a Keycloak configuration issue.

 
Token transmission via URLs

Despite being widely discouraged, access tokens are still occasionally transmitted through URL query parameters or redirects, especially in legacy systems. This practice poses a severe security risk, as tokens may be exposed through:

    • browser history,
    • server and proxy logs,
    • monitoring and analytics tools,
    • third-party integrations.

In multi-application IAM environments, such leakage can have cascading effects across multiple systems.

 
Incomplete PKCE or nonce support

Some client applications technically use the Authorization Code Flow, but fail to:

    • properly implement PKCE,
    • validate nonce values,
    • or explicitly enforce secure defaults in client libraries.

In complex deployments with numerous redirect paths and client types, this significantly increases the risk of authorization code injection attacks, even when Keycloak itself is correctly configured.

Missing security headers and improper cookie configuration

Finally, many audited applications lack basic web security hardening measures such as:

    • Content-Security-Policy (CSP),
    • HTTP Strict Transport Security (HSTS),
    • properly configured SameSite cookie attributes.

 

These controls are not managed by Keycloak, yet they play a crucial role in protecting authentication flows and user sessions at the application level.

Summary

Auditing a Keycloak deployment in an enterprise environment requires looking far beyond realm and client configuration screens. While proper Keycloak hardening is essential, the highest security risks typically arise from insecure client-side implementations and architectural decisions.

 

“Keycloak can be hardened perfectly, yet the overall security posture will always be defined by the weakest client application integrated with it.”

 

Based on practical audit experience in large, multi-realm Keycloak environments:

    • the most critical vulnerabilities emerge at the intersection of Keycloak and client applications,
    • correct IAM configuration does not mitigate insecure application behavior,
    • many high-impact issues can be resolved without changes to Keycloak itself, by improving application architecture and integration patterns.

 

A well-executed Keycloak security audit helps organizations reduce attack surface, standardize IAM integrations, and safely scale their identity infrastructure across teams, environments, and business units.

 

In large organizations, Keycloak effectively becomes the backbone of digital identity — and its real security strength is determined by the weakest link in the surrounding application ecosystem.

Artykuł Keycloak Deployment Auditing – General Scope and Guidelines pochodzi z serwisu Inero Software - Software Consulting.

]]> 8306 Secure Email Delivery in Keycloak 26.2 Using XOAUTH2 https://inero-software.com/secure-email-delivery-in-keycloak-26-2-using-xoauth2/ Mon, 15 Sep 2025 10:48:22 +0000 https://inero-software.com/?p=8141 Secure Email Delivery in Keycloak 26.2 Using XOAUTH2 Email has been one of the oldest and most fundamental services on the internet, used for notifications, password resets, verifications, and more. Over time we’ve seen major improvements — encryption via TLS, then STARTTLS, and now many providers are moving away from…

Artykuł Secure Email Delivery in Keycloak 26.2 Using XOAUTH2 pochodzi z serwisu Inero Software - Software Consulting.

]]>

Secure Email Delivery in Keycloak 26.2 Using XOAUTH2

Email has been one of the oldest and most fundamental services on the internet, used for notifications, password resets, verifications, and more. Over time we’ve seen major improvements — encryption via TLS, then STARTTLS, and now many providers are moving away from basic password authentication in favor of modern token-based schemes like XOAUTH2. With Keycloak 26.2, this evolution has arrived: Keycloak now supports XOAUTH2 for outgoing SMTP mail, adding greater security and compatibility with providers who have deprecated legacy authentication

1. What is XOAUTH2, and Why It Matters

XOAUTH2 is a means of authenticating to an SMTP (or other email-sending) server using an OAuth2 access token rather than a username + password. Some of the key benefits include:

    • Improved Security: Tokens can be more tightly controlled, with limited scope and lifetime.
    • Compliance with Modern Providers: Many providers are disabling basic auth.
    • Centralised and Auditable Auth: Easier management and rotation. Each client’s access can be revoked independently of other clients’ operations.
    • Reduced Risk of Credential Leakage: No raw passwords stored or transmitted.

2. How XOAUTH2 is Implemented in Keycloak 26.2

With version 26.2, Keycloak adds native support for XOAUTH2 when sending emails via SMTP. This means administrators can move away from static username and password credentials and instead configure Keycloak to obtain an OAuth2 access token at runtime.

In the Admin Console under Realm → Realm Settings → Email, you can now switch the Authentication Type from Password to Token (XOAUTH2). Once enabled, additional fields appear where you provide:

– Client ID and Client Secret from your identity provider (e.g., Azure AD).
– The OAuth2 Token Endpoint used to request an access token.
– Optional Scopes, depending on your provider (for Microsoft 365: https://outlook.office365.com/.default).
– A From address / SMTP username, which may still be required by the mail server.

Keycloak then handles the process of requesting and refreshing tokens using the Client Credentials Grant flow. You can use the “Test connection” button to verify that the configuration is correct and that emails can be sent successfully.

This approach aligns Keycloak with modern security standards and prepares deployments for providers that are phasing out legacy authentication.

Note: The Enable Debug SMTP option (visible at the bottom of the form) activates extended logging for outgoing email. When enabled, Keycloak produces detailed debug output of the SMTP communication, which can be very useful for diagnosing integration issues such as authentication failures, token retrieval problems, or TLS misconfigurations. It is recommended to use this setting only in testing or troubleshooting scenarios, as it may expose sensitive information in the logs.

Retirement of Basic Authentication for SMTP AUTH (Client Submission) in Exchange Online

Days
Hours

3. Why This Matters for Microsoft Azure / Office 365 Users

Microsoft has announced the retirement of Basic Authentication for SMTP AUTH (Client Submission) in Exchange Online. Starting March 1, 2026, Microsoft will begin phasing out Basic Auth, and by April 30, 2026, it will be completely disabled. This change directly impacts Keycloak deployments where outgoing emails are sent via Office 365 / Exchange Online SMTP.

If your Keycloak instance is still configured with a username and password for SMTP, it will stop working once Basic Auth is retired. The solution is to migrate to XOAUTH2 configuration in Keycloak 26.2.

By adopting XOAUTH2, you ensure:

    • Continued compatibility with Microsoft email services
    • Stronger security and compliance
    • Reduced risk compared to static credentials

4. Beyond XOAUTH2?

There’s even more going on in modern email delivery. Many email delivery platforms steer away from traditional SMTP protocol towards API-based approach (e.g. MailJet, SendGrid or MailGun). This gives more flexibility to integrators and allows platform providers to offer additional features. API-based email sending is not jet supported by Keycloak out-of-the-box, but this support can be added via custom extensions. Contact us if you are interested in integrating Keycloak with API-based email delivery platforms.

Conclusion

The addition of XOAUTH2 support in Keycloak 26.2 is more than just a feature upgrade — it’s an essential step for organizations that rely on Office 365, Gmail, or other providers who are deprecating legacy authentication. By adopting XOAUTH2 today, you can future-proof your Keycloak deployment, comply with provider requirements, and improve overall email security.

Artykuł Secure Email Delivery in Keycloak 26.2 Using XOAUTH2 pochodzi z serwisu Inero Software - Software Consulting.

]]> 8141 Keycloak or SaaS IdP? A Tech Leader’s Guide to Making the Right IAM Choice https://inero-software.com/keycloak-or-saas-idp-a-tech-leaders-guide-to-making-the-right-iam-choice/ Thu, 24 Jul 2025 07:45:53 +0000 https://inero-software.com/?p=8063 Introduction Shipping single sign‑on quickly is tempting. Stakeholders push for a smooth login experience, developers want to move on to core features, and security teams are eager to tick the “MFA enabled” box. The trouble is that identity and access management (IAM) decisions outlive launch days. Once you choose a…

Artykuł Keycloak or SaaS IdP? A Tech Leader’s Guide to Making the Right IAM Choice pochodzi z serwisu Inero Software - Software Consulting.

]]>

Introduction

Shipping single sign‑on quickly is tempting. Stakeholders push for a smooth login experience, developers want to move on to core features, and security teams are eager to tick the “MFA enabled” box. The trouble is that identity and access management (IAM) decisions outlive launch days. Once you choose a platform, you inherit its operational model, cost structure and compliance implications for years.

In this blogpost we provide technical leads some few crucial issues when evaluating Keycloak—an open‑source IAM platform that has become a go‑to choice in many Java and cloud‑native environments. Rather than a hands‑on tutorial, you’ll get a decision framework that starts with business realities. We’ll walk through seven questions that determine whether Keycloak fits your context. For each, you’ll see why it matters, how to assess it, the red flags to watch for, and a concrete deliverable to capture the outcome.

By the end, you’ll fill in a short scorecard and see if your organization toward Keycloak, a commercial SaaS IdP (Auth0, Okta, Azure AD B2C, etc.), or a hybrid path. If you want a sanity check, we offer a free 45‑minute Keycloak readiness consultation—no slides, just practical advice.

 

Where Keycloak Lives in Your Stack

Keycloak usually sits between your user‑facing applications and the identity sources they rely on. Applications delegate authentication and authorization to Keycloak. Keycloak can manage users internally or federate with LDAP/Active Directory. It also exposes logs and metrics that feed your SIEM and monitoring stack. Even if this picture seems obvious to engineers, spelling it out helps align legal, compliance and product stakeholders on who owns what.

Keycloak in a Nutshell (and Two Misconceptions)

Keycloak is an open‑source IAM server supporting OIDC, SAML, MFA, theming and an extension model (SPIs). Originally developed by Red Hat, it now thrives under a large community.

Misconception #1: “Open source = free to run”. The software is free, but production IAM also needs infrastructure, monitoring, upgrades and people. Misconception #2: “It’s just for developers”. In reality, without governance and processes, any IAM platform becomes a liability.

Seven Questions to Frame the Decision

 

Treat these questions as a workshop agenda, not a checklist. Bring security, operations, product and finance to the same table. The goal is to leave each session with an artifact that informs budgeting, architecture and planning.

 

1. Compliance & Risk: Do You Need Full Control Over IAM?

Regulatory frameworks such as NIS2 or GDPR—and sector standards like PCI DSS or HIPAA—often demand demonstrable control over identities, audit trails and incident response. If auditors expect you to produce detailed logs or prove exactly who changed what, a black‑box SaaS can create friction 

List the controls and evidence you must provide. Do you need to host IAM in a specific region? 

How quickly must you produce logs? Are you required to approve every policy change? 

If many answers point to tight control, Keycloak’s self‑hosted nature becomes an advantage.

 

The biggest red flag is deferring compliance: “we’ll pass audits later”. Another is that nobody owns IAM data retention or log policies.

 

Deliverable: a compliance checklist mapped to IAM features and governance processes.

2. Integration Map: How Many Apps and Protocols Today—and in
Two Years?

Integration effort—not software choice—usually drives project cost and timeline. Keycloak handles OIDC/SAML/LDAP well, but legacy systems and partner constraints can complicate
the picture. Inventory every application that authenticates users. Classify by protocol, business criticality and migration difficulty. Project changes over the next 24 months: new products,

acquisitions, vendor switches. 

 

Red flags: no authoritative app inventory; underestimating testing for each integration.

 

Deliverable: a prioritized integration backlog with rough sizing.

3. Team & Operations Capacity: Can You Secure and Run It
24/7 (or Outsource)?

IAM outages stop business. Someone must patch, monitor, respond to incidents and plan upgrades. Decide whether your DevOps/SecOps team can own this or you’ll offload parts to a partner.

Assess on‑call capacity, automation maturity, security expertise. Define SLAs, RTO/RPO. Consider managed services for routine ops while retaining architectural control 

 

Red flags: a single overworked DevOps, lack of monitoring/alerting, no upgrade plan.

 

Deliverable: a RACI matrix for IAM operations and an initial ops budget.

4. Customization Needs: Themes, Extensions and Advanced
Authorization

Keycloak’s extensibility is a major advantage: custom authenticators, advanced policies (ABAC), branded login flows, phishing‑resistant UX. If differentiation or strict UX/security is a
requirement, flexibility matters.

Gauge UX/theming demands, multilingual support, accessibility, device trust, passkeys, fine‑grained authorization.Each adds value to an extensible platform.

 

Red flags: assuming the default theme is enough; ignoring SPI development complexity.

 

Deliverable: a customization backlog with effort estimates and ownership.

5. Scalability & High Availability: What Are Your Peak
Loads and DR Needs?

If login fails, revenue stops. HA/DR design impacts infrastructure cost and complexity. You need clarity on peaks, acceptable downtime and recovery objectives.

Estimate peak concurrent logins (launch days, campaigns). Define RTO/RPO. Choose between VM clusters or Kubernetes with an operator. Decide on multi‑region strategies.

 

Red flags: “we’ll scale later”, skipping DR tests entirely.

 

Deliverable: an HA/DR architecture option matrix with pros, cons and cost

.

6. Budget & TCO: What Does Three Years Really Cost vs
SaaS?

Keycloak costs = infra + people + consulting. SaaS costs = subscriptions + add‑ons + overage fees.

Only a 3‑year TCO model reveals the truth.

Build a spreadsheet covering infra, backups, monitoring, labor, upgrades. Do the same for SaaS: MAU fees, advanced features, support tiers. Stress‑test both with growth scenarios.

 

Red flags: ignoring people costs, assuming maintenance is free, overlooking SaaS overage triggers.

 

Deliverable: a TCO calculator you can keep updating as data changes.

7. Vendor Lock‑In & Roadmap Control: How Much Flexibility
Do You Need?

Open source gives you architectural freedom. SaaS gives you speed but ties you to someone else’s roadmap and pricing. Sometimes that’s fine; sometimes it’s a risk.

Map likely IAM needs for 2–3 years. How critical is it to add custom flows quickly or hold back an upgrade? Could pricing shifts hurt you?

 

Red flag: ‘we’ll never need to extend’.
Organizations evolve and regulations shift.

 

Deliverable: a risk matrix—flexibility/control vs speed/convenience—plotting Keycloak, SaaS and Hybrid for your case.

 

A Visual Decision Flow

 

If your team prefers a diagram to spark discussion, start with the simplified flow below. It nudges you toward Keycloak, SaaS or Hybrid based on the dominant answers. Use it as an icebreaker, not as a final verdict.

Quantify It: The Scorecard

To make debates objective, translate the seven questions into numbers. Give each one a score from 1 to 5 (5 means a strong push toward Keycloak). Totals near the high end suggest Keycloak or Hybrid; lower totals suggest SaaS. More important than the number is the conversation it forces: why did we give compliance a 5 but ops capacity a 2?

Question
Score (1–5)
Notes
Leaning
Compliance & Risk: Do You Need Full Control Over IAM?
 
 
 
Integration Map: How Many Apps and Protocols Today—and in Two Years?
 
 
 
Team & Operations Capacity: Can You Secure and Run It 24/7 (or Outsource)?
 
 
 
Customization Needs: Themes, Extensions and Advanced Authorization
 
 
 
Scalability & High Availability: What Are Your Peak Loads and DR Needs?
 
 
 
Budget & TCO: What Does Three Years Really Cost vs SaaS?
 
 
 
Vendor Lock‑In & Roadmap Control: How Much Flexibility Do You Need?
 
 
 
Total / Recommendation
 
 
Keycloak / SaaS / Hybrid

 

From Decision to Deployment: A Pragmatic Pipeline

Assuming Keycloak is the direction, you still need a process to avoid chaos. We recommend a pipeline that mirrors proven delivery patterns: Discovery → Assessment → Architecture → PoC → Pilot → Production → Operate. Each phase ends with a clear artifact and go/no‑go gate.

Discovery clarifies drivers, constraints and stakeholders. Without this, technical work drifts. Assessment inventories integrations and compliance needs, and identifies risks and skill gaps.Architecture produces the reference design, HA/DR plan and governance model. PoC attacks the riskiest assumptions first—often a tricky integration or compliance requirement. Pilot rolls out to a subset of apps/users to validate processes, comms and support.

Production rollout happens in phases with rollback strategies (blue/green, canary).

Operate means continuous monitoring, patching, upgrades and cost optimization—often where a partner can help your team breathe.

 

Next Steps

If your scorecard favors Keycloak, schedule a Discovery & Governance workshop to align stakeholders, draft a high‑level architecture and turn assumptions into a roadmap. If you’re unsure, run a PoC targeting the top two risks. And if SaaS seems better today, design an exit strategy anyway—lock‑in is fine when it’s deliberate, not accidental.

 

 Ready to Validate Your Choice?

Book a free 45‑minute Keycloak Readiness Consultation. We’ll go through the seven questions together, fill out the scorecard and outline concrete next steps—whether that’s an internal PoC, a hybrid approach or a full advisory engagement.

 

FAQ

Is Keycloak free to use in production?

Yes. The software is open source, but production‑grade IAM still requires infrastructure, operations and security work. Some organizations use managed Keycloak or a consulting partner to offload that burden.

How long does a typical Keycloak deployment take?

A focused PoC can be done in weeks. Larger rollouts with dozens of integrations and strict compliance tend to span several months from assessment to stable production.

Can Keycloak meet NIS2/GDPR requirements?

Technically yes—Keycloak offers detailed logging, fine‑grained policies and MFA, and can be hosted where you need it. Compliance still depends on governance and evidence, not just tool capabilities.

Artykuł Keycloak or SaaS IdP? A Tech Leader’s Guide to Making the Right IAM Choice pochodzi z serwisu Inero Software - Software Consulting.

]]> 8063 Configuring Password Policies in Keycloak https://inero-software.com/configuring-password-policies-in-keycloak/ Thu, 20 Mar 2025 12:10:07 +0000 https://inero-software.com/?p=7635 In this blog, we will first take a look at the built-in Keycloak mechanisms for password policy management. Then, we will explore the possibilities for customizing these mechanisms to better fit specific requirements.

Artykuł Configuring Password Policies in Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]>

Effective password management is an important aspect of securing user accounts, and Keycloak provides tools to enforce strong authentication policies. By configuring password rules, administrators can ensure that credentials meet security standards, reducing the risk of unauthorized access. The framework offers flexible options, allowing you to set requirements for password length, complexity, expiration, and reuse prevention. 

In this blog, we will first take a look at the built-in Keycloak mechanisms for password policy management. Then, we will explore the possibilities for customizing these mechanisms to better fit specific requirements.

Built-in policies

These built-in password policies in Keycloak allow administrators to enforce security rules to strengthen user authentication. Here’s a brief description of each policy:

  1. Expire Password – Forces users to change their password after a specified period.
  2. Hashing Iterations – Determines the number of iterations for password hashing to enhance security.
  3. Not Recently Used – Prevents users from reusing their recent passwords.
  4. Password Blacklist – Blocks specific passwords from being used, typically to prevent weak or common passwords.
  5. Regular Expression – Allows enforcing a custom regex pattern for password validation.
  6. Minimum Length – Sets the minimum number of characters required in a password.
  7. Not Username – Prevents users from setting their username as a password.
  8. Not Email – Prevents users from using their email address as a password.
  9. Not Recently Used (In Days) – Prevents password reuse within a specified number of days.
  10. Not Contains Username – Ensures the password does not include the username as part of it.
  11. Special Characters – Requires passwords to contain at least one special character.
  12. Uppercase Characters – Enforces at least one uppercase letter in the password.
  13. Lowercase Characters – Requires at least one lowercase letter in the password.
  14. Digits – Ensures the password includes at least one numeric digit.
  15. Maximum Authentication Age – Sets a limit on how long authentication remains valid before requiring reauthentication.
  16. Hashing Algorithm – Specifies the hashing algorithm used for password encryption.
  17. Maximum Length – Defines the maximum allowable length for passwords.

Implementing custom policy using SPI

To implement a custom password policy in Keycloak, we should use the Service Provider Interface (SPI).

In this case, we define a custom password policy provider by implementing the PasswordPolicyProviderFactory interface:

				
					public class PasswordCustomPolicyProviderFactory implements PasswordPolicyProviderFactory {

	public static final Integer DEFAULT_VALUE = 1;
	public static final String MIN_PASSWORD_LIFETIME_ID = "minimumPasswordLifetime";

	@Override
	public String getId() {
    	return MIN_PASSWORD_LIFETIME_ID;
	}

	@Override
	public PasswordPolicyProvider create(KeycloakSession session) {
    	return new PasswordCustomPolicyProvider(session);
	}
[...]
}

Factory instantiates and returns a new instance of PasswordCustomPolicyProvider, which contains the actual validation logic for enforcing the minimum password lifetime. The MIN_PASSWORD_LIFETIME_ID constant serves as the unique identifier for this custom policy and DEFAULT_VALUE constant represents the default minimum password lifetime (in days) if no custom value is configured via admin console.

				
					public class PasswordCustomPolicyProvider implements PasswordPolicyProvider {
np.
   private static final String POLICY_VIOLATION_MESSAGE = "passwordLifetimeViolation";


   private final KeycloakSession keycloakSession;

   public PasswordCustomPolicyProvider(KeycloakSession keycloakSession) {
   	this.keycloakSession = keycloakSession;
   }


   @Override
   public PolicyError validate(RealmModel realm, UserModel user, String password) {
   	PasswordCredentialProvider credentialProvider = new PasswordCredentialProvider(keycloakSession);
   	PasswordCredentialModel credentialModel = credentialProvider.getPassword(realm, user);

   	if (credentialModel == null) {
       	return null;
   	}

   	long passwordCreationTime = credentialModel.getCreatedDate();
   	long currentTime = Time.currentTimeMillis();
   	long elapsedTime = currentTime - passwordCreationTime;

   	PasswordPolicy passwordPolicy = realm.getPasswordPolicy();
   	int minPasswordLifetimeDays = passwordPolicy.getPolicyConfig(PasswordCustomPolicyProviderFactory.MIN_PASSWORD_LIFETIME_ID);
   	long minPasswordLifetimeMillis = TimeUnit.DAYS.toMillis(minPasswordLifetimeDays);
   	return elapsedTime >= minPasswordLifetimeMillis ? null : new PolicyError(POLICY_VIOLATION_MESSAGE, minPasswordLifetimeDays);
   }
[...]
}

The PasswordCredentialProvider can access the stored password creation timestamp via the PasswordCredentialModel instance. It then computes elapsedTime as the difference between this timestamp and the current system time, representing how long the password has been in use.

Next, the PasswordPolicy object retrieves the password policy for the realm, extracts the minimum required password lifetime in days (minPasswordLifetimeDays), and converts it to milliseconds (minPasswordLifetimeMillis). The policy ensures that the password has been in use for at least the required duration. If this requirement is not met, a PolicyError is returned. The error message key is stored in POLICY_VIOLATION_MESSAGE, and its content can be customized within our theme. This allows us to define a user-friendly message that informs the user why the password change is restricted and how much time remains before a new password can be set.

In this way, we can define custom password policies in Keycloak when the default set of policies is insufficient for specific requirements. This flexibility allows for more granular control over user authentication and password management when we need it.

Customizing UI to improve user experience

By default, Keycloak displays unsatisfied password policies individually on the login page. This can be problematic for many users, especially when there are multiple policies that are not met. It can lead to a cluttered interface and make it harder for users to understand all the password requirements at once. To address this, you can customize the login screen to display a collective list of all unsatisfied password policies together, providing a clearer and more user-friendly experience.

				
					public class CustomFreeMarkerLoginFormsProvider extends FreeMarkerLoginFormsProvider {
/**
* Mapping between password policy provider IDs and custom messages
* Note: contains only standard policies that must be displayed in the UI
*/
private final Map<String, String> policyPropertyMessages = Map.of(
LengthPasswordPolicyProviderFactory.ID, MINIMUM_LENGTH_MESSAGE,
MaximumLengthPasswordPolicyProviderFactory.ID, MAXIMUM_LENGTH_MESSAGE,
DigitsPasswordPolicyProviderFactory.ID, MINIMUM_DIGIT_MESSAGE,
SpecialCharsPasswordPolicyProviderFactory.ID, MINIMUM_SPECIAL_CHAR_MESSAGE,
UpperCasePasswordPolicyProviderFactory.ID, MINIMUM_UPPERCASE_MESSAGE,
LowerCasePasswordPolicyProviderFactory.ID, MINIMUM_LOWERCASE_MESSAGE,
NotUsernamePasswordPolicyProviderFactory.ID, NOT_USERNAME_MESSAGE,
NotContainsUsernamePasswordPolicyProviderFactory.ID, NOT_CONTAINS_USERNAME_MESSAGE,
NotEmailPasswordPolicyProviderFactory.ID, NOT_EMAIL_MESSAGE
);

[...]

@Override
protected void createCommonAttributes(Theme theme, Locale locale, Properties messagesBundle,
UriBuilder baseUriBuilder, LoginFormsPages page) {
super.createCommonAttributes(theme, locale, messagesBundle, baseUriBuilder, page);
if (realm != null && realm.getPasswordPolicy() != null) {
attributes.put("passwordPolicies", getPasswordPolicyMessages(realm.getPasswordPolicy(), messagesBundle));
}}

[...]

private Map<String, String> getPasswordPolicyMessages(PasswordPolicy passwordPolicy, Properties messagesBundle) {
Map<String, String> policyMessages = new HashMap<>();
PasswordPolicy.Builder builder = passwordPolicy.toBuilder();
for (String policyName : passwordPolicy.getPolicies()) {
var value = builder.get(policyName);
String message = extractPolicyMessage(policyName, value, messagesBundle);
if (message != null) {
policyMessages.put(policyName, message);
}
}
return policyMessages;
}

[...]

/**
* Extracts a message for a given password policy from the messages bundle
* Note: Policy message is constructed by replacing the {0} placeholder with the policy value
*/
private String extractPolicyMessage(String policy, String value, Properties messagesBundle) {
String property = policyPropertyMessages.get(policy);
if (property == null) {
return null;
}
String policyMessage = messagesBundle.getProperty(property);
return policyMessage != null ? policyMessage.replace("{0}", value) : null;
}

The getPasswordPolicyMessages() function already collects the password policies from the PasswordPolicy and maps them to the appropriate messages from the message bundle. You can extend this function to display all unsatisfied policies in one collective message.

 

Password policies such as minimum length, required digits, special characters, etc., are mapped to messages via the extractPolicyMessage() method. Our service implementation will iterate through each policy and check if it’s satisfied. If not, the corresponding message will be displayed.

 

In your update-password.ftl page, you can display these unsatisfied policies as a list using FreeMarker.

				
					
    	<#if passwordPolicies?has_content>
        	<div class="${properties.kcAlertClass}">
            	<div class="${properties.kcAlertIconWrapperClass}">
                	<span class="${properties.kcAlertIconClass}"></span>
            	</div>
            	<span class="${properties.kcAlertTitleClass}">
            	${msg("passwordInstruction")} <br>
            	<#list passwordPolicies?keys as key>
                	<span class="${properties.kcAlertTitleClass}">&#x2022; ${passwordPolicies[key]}</span><br/>
            	</#list>
            	</span>
        	</div>
    	</#if>

Real world policy examples

Let’s see how password policies look in large companies.

 

Apple requires passwords to be at least eight characters long and must include both letters and numbers. Additionally, passwords cannot contain three or more consecutive identical characters and cannot be commonly used passwords.

 

Facebook enforces a minimum password length of more than six characters, although longer passwords are recommended. While Meta does not require the use of special characters or digits, it encourages creating complex passwords.

 

Microsoft passwords must be at least 8 characters long and contain at least two of the following types of characters: uppercase letters, lowercase letters, digits, and symbols. Additionally, it may block the ability to set a password that is too similar to the previous one.

Although these companies use different tools for authentication, it’s important to consider the security standards implemented in big real-world systems.

 

And despite the fact that these password policies are not extremely restrictive, users should still avoid using sensitive personal information, such as names, birthdates, or phone numbers, in their passwords. Additionally, it’s essential to avoid reusing passwords across different services, as this can lead to vulnerabilities in case one account is compromised. Employing two-factor authentication (2FA) and periodically reviewing password security are further steps users can take to enhance their protection.

Summary

As you can see now, Keycloak provides a set of default password policies that cover standard security rules, such as minimum length, complexity requirements, and password history. These built-in policies are sufficient in many cases, but if needed, there is the option to customize them to meet specific organizational requirements. Keycloak also allows the creation of custom password policies, providing greater control over security.

In addition to customizing policies, Keycloak enables modification of the user interface, which is especially useful when the default display of password policy violations, such as showing unmet requirements individually, does not meet our needs. In such cases, we can change how errors are presented or enrich the messages with additional details to make them more user-friendly.

 

With these options, Keycloak demonstrates a high level of flexibility, allowing full control over security policies and the user interface, making it a versatile solution for identity and access management. The ability to define custom rules and adjust components ensures that Keycloak is a scalable tool that can be easily tailored to the specific needs of an organization.

Artykuł Configuring Password Policies in Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]> 7635 Setting Up Passwordless Login with Passkey on a Mobile Device https://inero-software.com/setting-up-passwordless-login-with-passkey-on-a-mobile-device/ Wed, 12 Mar 2025 07:47:03 +0000 https://inero-software.com/?p=7534 This blog focuses on configuring Passkeys specifically for mobile devices, ensuring a seamless and secure passwordless experience.

Artykuł Setting Up Passwordless Login with Passkey on a Mobile Device pochodzi z serwisu Inero Software - Software Consulting.

]]>

In our previous post, we demonstrated how to configure Passkeys in Keycloak, replacing traditional passwords with WebAuthn-based authentication. We covered the setup process, key advantages, and potential limitations, including the challenge of user adoption. This blog focuses on configuring Passkeys specifically for mobile devices, ensuring a seamless and secure passwordless experience.

Our first publication about Passkeys in Keycloak, you can find here: An introduction to Passkey with Keycloak

In this post, we’ll dive deeper into optimizing Passkey authentication in Keycloak, looking into a different approach, this time using more than one device.

Using a Passkey stored on a phone

When logging in on a different device, such as a laptop or desktop, users can authenticate using a Passkey stored on their phone. The process works as follows:

  1. Selecting Passkey Login
    Instead of entering a password, users choose the Passkey authentication option. The laptop’s browser generates a request for authentication. Now we have to establish a secure connection between your phone (e.g., iPhone) and your laptop.
  2. Scanning a QR Code
    The login interface generates a QR code, which users scan using their phone’s camera. Then the laptop sends a cryptographic challenge to the phone, asking it to sign a request using the stored passkey. The phone communicates securely with the laptop over Bluetooth or other close-range communication protocols (like NFC).
  3. Confirming Identity
    Once the phone receives the challenge, it asks the user for biometric authentication (e.g., Face ID or Touch ID). This verifies that the person attempting the login is the authorized user.
  4. Secure Authentication
    The laptop checks the response from the phone, verifying the cryptographic signature against the public key registered with the service. If the verification is successful, the user is logged in without having to enter a password.

Step by step: Configuring Passkey with a smartphone

Before we dive into our custom authentication flow, it’s important to check if the Webauthn Register Passwordless required action is enabled in the realm (Authentication -> Required actions tab).

This gives us, for example, the ability to enforce passkey configuration from users after their next successful login. However, it’s important to remember that this is just one of many ways to configure multiple authentication methods.

Once we confirm that this option is active, we can proceed with configuring the authentication flow.

This custom authentication flow for Keycloak is designed to demonstrate how users can choose between password-based authentication and passkey authentication (WebAuthn) during login. Here’s how it works:

    • Users are required to provide their username to proceed with authentication.
    • This step enforces authentication, but users can choose between password-based login or passkey-based login.
    • If the user opts for password authentication, they enter their credentials here.
    • If the user prefers passwordless authentication using passkeys, they can authenticate using this method instead.

In this step, users can enter their username or email to proceed with authentication. This is a required step, ensuring that the system identifies the user before offering authentication options.

At this stage, we can only use password authentication because we haven’t configured our Passkey (WebAuthn) yet. Once Passkey is set up, users will have the option to choose between password-based and passwordless authentication.

Instead of registering a device PIN as mentioned earlier, we will use authentication via a phone, specifically an iPhone, in this example

Now, a QR code should appear, allowing us to register a Passkey on our account. Let’s scan it using our phone’s camera and verify the operation, for example, using Face ID.

Now, our Passkey should be visible in the Credentials section.

During the next login, we should see the option to choose between password authentication and Passkey authentication.

 

This setup enhances user convenience by allowing them to pick their preferred authentication method. Passkeys provide a more secure and phishing-resistant login experience, while passwords remain available for users who prefer traditional authentication. With this flexibility, we can ensure both security and ease of access for different user preferences.

 

It is worth remembering that traditional passwords are a weak link in digital security, often compromised through reuse, phishing, or data breaches. Passkeys offer a modern, passwordless authentication method that enhances security and usability by leveraging cryptographic key pairs managed by platform authenticators. They provide phishing resistance, seamless multi-device access, and compliance with multi-factor authentication (MFA) standards.

Best Practices in Keycloak: Secure Your System in 5 Steps

Read more

Artykuł Setting Up Passwordless Login with Passkey on a Mobile Device pochodzi z serwisu Inero Software - Software Consulting.

]]> 7534 Trusted devices in Keycloak https://inero-software.com/trusted-devices-in-keycloak/ Thu, 06 Mar 2025 10:47:08 +0000 https://inero-software.com/?p=7522 The trusted devices mechanism in Keycloak is a way to enhance login convenience without significantly compromising cybersecurity.

Artykuł Trusted devices in Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]>

User authentication in IT systems requires finding a balance between convenience and security. On one hand, users expect the login process to involve the fewest steps possible; on the other, it is essential to protect system access from unauthorized use. One way to manage security levels flexibly is through the trusted devices mechanism, which allows users to reduce the number of required login steps for recognized and secure devices.

The stricter the security policy, the more inconvenient it becomes for users—this is the eternal dilemma for system administrators. Long and complex passwords, frequent password changes, and additional authentication factors enhance security but also lead users to find ways to bypass procedures—such as writing passwords down in notebooks or saving them in browsers.

Trusted Devices – How Does It Work?

By default, Keycloak does not recognize or remember devices, meaning each session is treated independently. However, with extensions, support for trusted devices can be added, allowing users to skip certain steps during subsequent logins.

 

CTO of Inero Software, Waldemar Korłub, emphasizes:

"Hence the concept of trusted devices – the first time, we need to go through all the steps, but afterward, the application can, for example, skip asking for the two-factor authentication code."

Once a device is marked as “trusted,” the system can retain its status for a specified period, allowing for a simplified login process. However, the user may still be periodically asked to reauthenticate to ensure security.

Is remembering devices secure?

While the trusted devices mechanism improves user convenience, it also introduces additional risks. The biggest threat is the theft or loss of a device that has been previously marked as trusted.

As Waldemar Korłub points out:

"If the system does not require an additional authentication factor, an attacker could gain access to all stored applications. That’s why it is crucial for users to have control over their trusted devices—ideally through a panel where they can remove them at any time."

Introducing a device management panel and the option to revoke a device’s trusted status in case of loss are essential elements for ensuring security.

How can administrators control access in Keycloak?

Administrators can restrict the device remembering mechanism, for example, to specific networks or corporate devices.

Waldemar Korłub explains:

"We can limit this mechanism, for example, to computers within the local network—if users connect via the corporate VPN, we can recognize company-owned devices and enable the trusted devices option for them."

Thanks to such solutions, organizations can prevent users from assigning trusted status to personal devices that are beyond their control.

Trusted Devices in Keycloak – Key Takeaways

    • Trusted Devices Help Simplify Login but Require Proper Security Measures

      The trusted devices mechanism in Keycloak allows users to skip certain authentication steps, such as entering a 2FA code. While this is a convenient solution that streamlines daily operations, it also requires the implementation of appropriate security measures. It is essential to define the validity period of a trusted device and monitor changes in login behavior to prevent misuse.

    • Administrators Can Control the Trusted Device Access Policy

      Not every device should be marked as trusted, which is why administrators can restrict this feature to corporate computers or require a VPN connection. This helps prevent situations where a user assigns trusted status to a personal computer that the organization cannot control.

    • Device Management Panel Enhances Security

      To give users greater control over their sessions, it is beneficial to implement a panel that allows them to review and remove trusted devices. This way, in case of device loss or suspected unauthorized access, users can quickly revoke granted permissions.

    • The Ability to Remove a Device Protects Against Account Takeover

      If a device is lost or stolen and the system does not require additional authentication, an attacker could gain access to the user’s account. That’s why it is crucial to allow the removal of trusted devices at any time and enforce reauthentication. This approach provides greater flexibility while reducing the risk of unauthorized account access.

When Should You Use the Trusted Devices Feature in Keycloak?

The trusted devices feature in Keycloak enhances login convenience while maintaining a high level of security. This functionality is particularly useful in corporate environments and BYOD (Bring Your Own Device) models, where users regularly log in from the same devices.

Marking a device as trusted reduces the number of two-factor authentication (2FA) prompts, extends session duration, and allows for dynamic security policy adjustments, such as requiring reauthentication for suspicious logins. This approach helps mitigate the risk of account takeover—even if an attacker obtains a password and 2FA code—since logging in from a new device may trigger additional verification.

Implementing trusted devices in Keycloak enables organizations to strike a balance between security and user convenience.

The trusted devices mechanism in Keycloak enhances login convenience without significantly compromising cybersecurity. Proper implementation of the device remembering policy in Keycloak helps balance system security and user experience.

However, administrators should ensure that mechanisms are in place for managing the list of trusted devices and enforcing periodic verification of their status to mitigate potential security risks.

We will help you implement Keycloak

Want to implement Keycloak or add new functionalities? Schedule a meeting to explore the possibilities.
Schedule a meeting

Artykuł Trusted devices in Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]> 7522 An introduction to Passkey with Keycloak https://inero-software.com/an-introduction-to-passkey-with-keycloak/ Wed, 26 Feb 2025 08:11:28 +0000 https://inero-software.com/?p=7417 In this blog post, we’ll show you how to set up Passkeys based on the Keycloak.

Artykuł An introduction to Passkey with Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]>

Traditional passwords have long been a weak factor in digital security. They are often reused, easy to compromise, and vulnerable to phishing attacks. Passkeys offer a modern solution by replacing passwords with app-specific cryptographic key pairs managed by platform authenticators. Because passkeys involve multiple authentication touchpoints, they meet multi-factor authentication (MFA) requirements and align with multiple standards.

In this blog post, we’ll show you how to set up Passkeys based on the Keycloak configuration we’ve covered in previous posts (check Securing Java Spring Endpoints with Keycloak or Hands-On Keycloak SSO: From Setup to Integration). While passkeys promise a seamless and secure authentication experience, integrating them into an existing system can come with its own challenges. We’ll guide you through the basic setup process. If you’re looking to modernize your authentication strategy, this is the perfect place to start.

How it works

Passkeys are a passwordless authentication method designed to replace traditional passwords with a more secure and convenient alternative. Unlike passwords, which can be phished, stolen, or forgotten, passkeys eliminate these risks by using cryptographic key pairs stored in a trusted authenticator, such as a smartphone, another device, or a password manager. Instead of manually creating and remembering a password, users enable an authenticator to generate and manage a passkey for them. In general, a passkey consists of two parts:

    • A public key, which is stored by the application
    • A private key, which remains securely stored in the user’s authenticator

The private key never leaves the device, ensuring that even if the public key is compromised, accounts remain secure.

  1. When logging in, the app sends a challenge to the authenticator.
  2. The user verifies their identity using biometrics (Face ID, Touch ID), a PIN, or a password.
  3. The authenticator signs the challenge with the private key and sends it back for verification.
  4. If the signature is valid, access is granted – without ever needing a password.

Advantages of Passkeys

    • Unlike passwords, passkeys can’t be stolen through phishing attacks. They are bound to a specific website or app, meaning they won’t work on fake login pages. Even if a user visits a phishing site, their passkey won’t be prompted and won’t sign them in, preventing credential theft.
    • Users don’t have to manage multiple passwords across accounts. Logging in is as simple as using Face ID, Touch ID, or a device PIN.
    • Passwords can be guessed, reused, or leaked—passkeys can’t. Even some 2FA methods (like SMS codes) are vulnerable to phishing and SIM-swapping, while passkeys are not. Since passkeys use public-key cryptography, they can’t be stolen or intercepted in a data breach.
    • Passkeys are stored in platform authenticators (e.g., Google Password Manager, Windows Hello). They can be automatically synced across devices, ensuring access without manual transfers.

Limitations of Passkeys

    • Not all websites and applications support passkeys yet, meaning users may still need to rely on passwords for some services.
    • Losing access to a primary device or cloud account could lock users out, requiring recovery options like backup devices.
    • Many users are still unfamiliar with passkeys, and the transition away from passwords requires education. Since passkeys don’t require manual entry, users may feel a lack of control over their credentials compared to traditional password management.

Configuring Passkey for the Realm

Keycloak provides flexible authentication options, traditionally relying on passwords and OTP-based multi-factor authentication (MFA). However, with the rise of passwordless security, Keycloak also supports WebAuthn Passwordless (Passkeys). In this setup, we will disable both passwords and OTP authenticators, ensuring that users can only log in using Passkeys. 

The order of authenticators determines the login workflow in Keycloak. We keep the cookie authenticator to allow users to maintain active sessions. To support external authentication, we enable the Identity Provider Redirect, allowing users to log in via upstream providers like Google, or another Keycloak instance. Next, we configure the actual login form. By default, Keycloak’s browser flow includes username, password, and MFA authentication. We can disable everything in this section and replace it with a single step: adding a WebAuthn Passwordless Authenticator, ensuring that users can only log in using Passkeys. The final flow should look something like this:

 

Once the WebAuthn Passwordless Authenticator is set up, the next step is to bind the authenticator to the browser login flow.

Now, all that’s left is to force a password reset for our sample user by setting the required action to WebAuthn Register Passwordless.

After clicking the link in the received email, Keycloak will display a dialog instructing the user to register their passkey.

Just click to register the passkey.

Your device’s platform authenticator will appear showing available options for confirming the user’s identity. Let’s assume we want to use Windows Hello and confirm identity with a PIN code – the same that is used when logging into the Windows account.

The passkey should now be visible in the credentials section of the specified user.

Now we can go to the realm’s login page and try using our passkey instead of the standard username and password.

Your platform authenticator should appear again, offering to use the registered passkey.

 

Passkeys aren’t perfect, but their benefits outweigh their drawbacks for most users. As adoption increases, many of these limitations will be addressed. However, in the short term, users and organizations need to be aware of potential challenges when integrating passkeys into their authentication workflows. Organizations seeking to integrate passkeys into their authentication systems can leverage tools like Keycloak. By integrating passkeys into Keycloak, organizations can provide users with secure, passwordless access to applications while still benefiting from Keycloak’s major features like Single Sign-On (SSO), multi-factor authentication (MFA), and fine-grained access control.

Artykuł An introduction to Passkey with Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]> 7417 Cybersecurity: More Than Just Antivirus Software https://inero-software.com/cybersecurity-more-than-just-antivirus-software/ Tue, 18 Feb 2025 12:54:19 +0000 https://inero-software.com/?p=7231 Cybersecurity experts point out that these techniques continue to evolve and adapt to better target potential victims. In 2025, it is worth paying attention to three key areas.

Artykuł Cybersecurity: More Than Just Antivirus Software pochodzi z serwisu Inero Software - Software Consulting.

]]>

For many people, the first thing that comes to mind when talking about cybersecurity is antivirus software. However, modern cyber threats go far beyond traditional computer viruses. While antivirus software remains an important element of protection, an effective strategy for preventing attacks and minimizing the risk of data or financial loss must encompass a much broader range of tools and processes.

Cybercriminals have a vast arsenal of attack techniques and methods. In public discourse, terms such as phishing, ransomware, DDoS (Distributed Denial of Service) attacks, and social engineering are frequently mentioned.

On which threats should we focus in 2025?

Cybersecurity experts point out that these techniques continue to evolve and adapt to better target potential victims. In 2025, it is worth paying attention to three key areas:

Passkeys are replacing passwords

Passwords remain a weak link. With the rise of phishing and authentication attacks, companies are shifting to passkeys—biometric or cryptographic authentication methods that enhance security and user convenience. Tech giants like Google and Apple are leading this transition.

Phishing is becoming hyper-personalized

Generic phishing emails are a thing of the past. Attackers now use in-depth research and social media data to create highly targeted campaigns that appear legitimate. AI-generated messages mimic real conversations, making social engineering more effective. Organizations must invest in advanced detection and employee awareness to stay protected.

Deepfakes are a growing threat

AI-powered deepfake technology is becoming an increasing cybersecurity threat. Criminals use AI-generated profiles impersonating managers or other trusted individuals to bypass security measures and manipulate employees into revealing confidential information. One well-known method involves using filters during video calls to impersonate someone in real time. Companies must strengthen verification protocols and educate employees on detecting deepfakes.

When antivirus software is not enough

Antivirus software is designed to detect, block, and remove malicious programs such as viruses, trojans, and spyware. Its functionality relies on databases of known threats. However, cybercriminal techniques are evolving beyond the capabilities of traditional antivirus solutions. Attacks like phishing, ransomware, social engineering, and deepfakes are not directly linked to classic malware and often require more advanced protection methods.

How to stay secure?

First and foremost, by implementing modern authentication methods, identity management, and incident detection systems that can indicate potential attacks. This includes using multi-factor authentication (MFA), integrating with identity management systems like Keycloak, and monitoring activity through SIEM (Security Information and Event Management) tools. Such an approach enables real-time identification and response to unusual behavior that may signal a system compromise.

We wrote about why integrating Keycloak with a Security Information and Event Management (SIEM) system is worth considering here.

Start by structuring the process

A well-structured cybersecurity process begins with a thorough risk assessment and threat identification. At this stage, an organization inventories all IT assets, including devices, systems, applications, and data. It is crucial to determine which of these assets are the most sensitive and require special protection. Next, a risk analysis should be conducted to evaluate potential threats, their impact on business operations, and the likelihood of occurrence. This helps identify the key areas that require the most protection.

 

The next step is to develop a comprehensive security policy. This includes a set of rules and procedures governing all aspects of technology use within the organization—from password and access management to guidelines for mobile device usage and remote work. At this stage, it is essential to consider applicable legal regulations, such as GDPR, and industry standards.

 

Once policies are established, the next step is implementing the necessary security technologies and tools, such as the previously mentioned Keycloak. This stage involves integrating security measures like multi-factor authentication (MFA), data encryption, and IT infrastructure monitoring systems like SIEM (Security Information and Event Management). Simultaneously, mechanisms for regular software updates and data backups should be introduced to enable quick system recovery in the event of an incident.

 

When designing a cybersecurity process, it is important to recognize that humans are often the weakest link in security. Increasing employee awareness through training programs is critical. These programs educate staff on different attack techniques and real-world examples, helping them identify potential threats.

 

The final, but equally important, component is monitoring and incident response. Organizations should have clearly defined procedures for responding to security breaches, ensuring rapid detection, analysis, and mitigation of cyberattacks.

We will help you implement Keycloak

Schedule a meeting to learn how we can help you implement and fully manage Keycloak in your organization.
Schedule a meeting

Artykuł Cybersecurity: More Than Just Antivirus Software pochodzi z serwisu Inero Software - Software Consulting.

]]> 7231 Behind the Scenes #2: Implementing email-based MFA in Keycloak https://inero-software.com/behind-the-scenes-2-implementing-email-based-mfa-in-keycloak/ Thu, 13 Feb 2025 09:50:32 +0000 https://inero-software.com/?p=7042 In this post, we’ll explore a custom MFA implementation that sends a one-time authentication code to the user’s email.

Artykuł Behind the Scenes #2: Implementing email-based MFA in Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]>
Keycloak natively supports many secure login solutions and comes with built-in one-time password (OTP) mechanisms, such as authentication via mobile apps like Google Authenticator or our solution AuthM8. However, if we want to use other advanced authentication methods and for example send OTP codes via email, then similar to SMS multi factor authentication (more details HERE), we need to implement this functionality ourselves. In this post, we’ll explore a custom MFA implementation that sends a one-time authentication code to the user’s email. 

How does email-based MFA work?

The authentication process consists of two main stages:

    • Generating and sending the MFA code

If the user already has an active cookie confirming a previous MFA verification, they should be immediately authenticated. Otherwise, Keycloak creates a new credential for the user and generates a one-time code based on configurable parameters like length or time-to-live.  The code is stored in the user’s credentials and then is emailed using the email provider.

 

    • Verifying the entered code

When a user submits the code, KC retrieves the stored credential and compares the entered value. If the code is correct and still valid (not expired), authentication is successful, and a cookie is set to remember the verification. If the code is incorrect, the user is prompted to re-enter it and if the code has expired, an error message is shown and the process must be restarted.

Email MFA: Pros and Cons

Email-based MFA offers additional security when the primary factor, such as a password, has been compromised. This is particularly helpful in cases where passwords are brute-forced or easily guessed, such as with common combinations like 123456. Similarly, this solution offers protection against credential stuffing, where attackers use leaked passwords from other breaches to attempt logging into account.

There are several other benefits to using email as a MFA:

    • Email MFA does not require users to provide additional sensitive information, such as a phone number, reducing concerns about privacy.
    • It does not require users to install a separate app or complete a complicated setup, which simplifies the process.
    •  Users are accustomed to providing their email for various purposes, such as receiving important account updates or resetting passwords. This familiarity makes it more accessible.

However, email as a delivery channel does have some drawbacks. If an attacker compromises your email (gains access to an email account through stolen credentials or by exploiting an active session.), they could potentially reset other accounts’ passwords as well. For users in vulnerable situations, such as those with access to shared devices, email-based MFA can still leave them exposed. As with any security measure, it’s essential to weigh the benefits against the potential risks and mix email MFA with other safeguards, such as strong passwords policy and secure email practices.

Implementing Email MFA

In this modified Browser Authentication Flow, we integrate our custom MFA as an additional authentication method. There are two new steps:

    • MFA Email setup – this step ensures that email is set up and verified for the user before proceeding. If the user does not have a custom MFA Credential (which stores OTP codes as secrets), it will be set as well.
public class MfaEmailSetupAuthenticator implements Authenticator, CredentialValidator<MfaEmailCredentialProvider> {
@Override
public void authenticate(AuthenticationFlowContext context) {
[…]
// Require email verification
if (!userModel.isEmailVerified()) {
userModel.addRequiredAction(UserModel.RequiredAction.VERIFY_EMAIL);
}
// Add MFA email credential if not present
if (!getCredentialProvider(context.getSession()).isConfiguredFor(realmModel, userModel, MfaEmailCredentialModel.TYPE)) {
userModel.credentialManager().createStoredCredential(new MfaEmailCredentialModel(new MfaEmailCredentialData()));
}
[…]
    • MFA Email Authentication – this is the actual authentication step where a one-time code is sent via email. Marked as Alternative, meaning it can be used instead of other MFA methods like mobile app OTP.

Here, you can see how the configuration of this authenticator could look like in the Keycloak authentication flow.

    • Max Cookie Age this setting determines how long the MFA session (cookie) is valid. If the cookie is still valid, the user won’t be prompted for MFA. 
    • Time-to-live indicates the lifetime of the MFA code.

 

Now let’s take a look at the code. 

 

The method below handles the MFA process itself. If a valid cookie exists (indicating that the user has already completed MFA), the method immediately returns success, meaning the authentication flow is complete without requiring additional actions.

@Override
public void authenticate(AuthenticationFlowContext context) {
if (hasValidCookie(context)) {
context.success();
return;
}
[…]

If there is no cookie, we should try to retrieve the user’s existing MFA credential from the credential provider. If the user doesn’t have one, a new instance is created using the MfaEmailCredentialModel which just extends the built-in CredentialModel:

[…]
// get existing credential or create a new one
CredentialModel credentialModel = getCredentialProvider(session)
.getDefaultCredential(session, context.getRealm(), user);
if (credentialModel == null) {
credentialModel = user.credentialManager().createStoredCredential(new MfaEmailCredentialModel(new MfaEmailCredentialData()));
}
[…]

Then the authenticate method reads configuration properties like code length and TTL (time-to-live). The code itself can be generated using some utils method and will be stored as the secretData in the credential model.

// generate and store code
int length = Integer.parseInt(configMap.get(CONFIG_CODE_LENGTH));
int ttl = Integer.parseInt(configMap.get(CONFIG_CODE_TTL));
String code = MfaEmailCodesUtils.generateCode(length);
credentialModel.setSecretData(code);
user.credentialManager().updateStoredCredential(credentialModel);
AuthenticationSessionModel authSession = context.getAuthenticationSession();
authSession.setAuthNote("ttl", Long.toString(System.currentTimeMillis() + (ttl * 1000L)));

In the end the sendCode method is called to send the generated code to the user’s email. If the email is sent successfully, the method presents the form where the user can enter the MFA code.

// send email and show input form
try {
MfaEmailCodesUtils.sendCode(session, user, ttl, code, configMap);
context.challenge(context.form().setAttribute("realm", context.getRealm()).createForm(TPL_CODE));
} catch (Exception e) {
context.failureChallenge(AuthenticationFlowError.INTERNAL_ERROR,
context.form().setError("mfaEmailNotSent", e.getMessage())  .createErrorPage(Response.Status.INTERNAL_SERVER_ERROR));
}

The second major part of our Authenticator is the action method which handles the validation of the code entered by the user. It is invoked when the user submits the input form after receiving the email.  

The method retrieves the user’s credential from the provider and then the code is validated by checking it against the stored credential using the custom isValid method.

[…]
final MfaEmailCredentialModel credentialModel = getCredentialProvider(session)
        .getDefaultCredential(session, context.getRealm(), user);
boolean isValid = getCredentialProvider(session).isValid(context.getRealm(), user,
     new UserCredentialModel(credentialModel.getId(), getCredentialProvider(context.getSession()).getType(), enteredCode));
[…]

If the code is valid, the next step is to check if it is expired. We can also set a cookie that stores the MFA session to prevent the user from being prompted for MFA again during the cookie’s validity period.

[…]
// valid
HttpResponse response = context.getSession().getContext().getHttpResponse();
response.setCookieIfAbsent(createCookie(context));
context.success();
[…]

 

Of course, in this post, we will not cover the entire topic, omitting implementation details such as sending the code, generating the code, validation, and creating our custom cookie.


However, we have walked through the major steps of implementing 2FA using email-based codes. On the one hand, this approach offers a simple and accessible solution. Although it has its drawbacks, using it in solutions like Keycloak helps mitigate many of these vulnerabilities. Keycloak also provides the flexibility to combine email-based MFA with other security measures, creating a more layered and resilient authentication process that can help protect against evolving cybersecurity threats.

Do you need help configuring multi-factor authentication?

Schedule a meeting to find out how we can help you.
Schedule a meeting

Artykuł Behind the Scenes #2: Implementing email-based MFA in Keycloak pochodzi z serwisu Inero Software - Software Consulting.

]]> 7042