Your branding and your login logic, carried through every Keycloak upgrade

We build themes, login steps and extensions that sit outside the Keycloak core, so the next upgrade does not undo them.

Sound familiar?

Which of these sounds like your team?

Keycloak's default look

Users leave your product's design behind and land on a stock login screen.

A login rule Keycloak can't express

Your process calls for a check during sign-in that no built-in setting covers.

Accounts stored elsewhere

Keycloak would need to read user records from a legacy application or your own database.

Thin tokens

Your services look up the customer or tenant ID separately because the token doesn't carry it.

Sign-in events go nowhere

Failed logins and suspicious attempts never reach your security tools.

Pinned to a past release

Upgrading would break extensions that were written for a release long ago.

Process

How we work

  1. 01

    Agree the change

    We write down the behaviour you need and confirm that configuration alone can't deliver it.

  2. 02

    Build outside the core

    Your themes and extensions ship as their own packages, so Keycloak itself stays untouched.

  3. 03

    Test against releases

    Your applications run against the new code, and so do newer Keycloak releases.

  4. 04

    Decide who owns it

    Your developers get full documentation, or Grootan keeps the code current.

Specifics

Technical details

  • Themes for every screen people see, from sign-in and self-service account pages to outgoing emails and the admin console, built in FreeMarker or in React via Keycloakify, and usable on phones and with screen readers
  • When a login needs an extra step, we write a custom authenticator and wire it into a new flow
  • A User Storage SPI provider lets Keycloak sign people in against a legacy system, an API or your database without importing them
  • Your apps receive the extra claims they need, added by custom token mappers
  • Login and admin events flow into your SIEM or log platform through an event listener
  • When a new Keycloak release comes out, each extension is built and tested against it, and every version is tracked

Options

Flexible to fit you

  • Templates in FreeMarkerorA React front end via Keycloakify
  • Stay with built-in settingsorWrite code where settings can't do it
  • Keycloak reads accounts where they already liveorAccounts are copied into Keycloak
  • Grootan maintains the codeorIt becomes your developers' code

Measurement

What we measure

  • How many login attempts end with the user inside the app
  • Seconds before the sign-in screen is ready
  • Keycloak releases adopted with zero changes to our code
  • Help-desk calls caused by sign-in problems

FAQ

Questions we hear

Can sign-in look like the rest of our product?

Yes. Give us your design system and we apply it to the login screens, the account console and the emails, built to work on phones and with screen readers.

What happens to our extensions when Keycloak releases a new version?

If nobody checks, they can stop working. Ours stay out of the core and get tested on each release, so problems show up before your upgrade rather than during it.

Our users are in a database already. Do they have to be copied into Keycloak?

No. With user federation, Keycloak checks credentials against that database directly.

How do you price custom development?

There is no fixed rate. It depends on what you need built and how complex it is, and we go through that with you on a first call.

Let's shape Keycloak around your product

Related

More Keycloak services