What Is the Keycloak-Hosted Login Page?
Every time an app redirects you to Keycloak's own login screen instead of showing its own form, it's using the hosted login page. This guide explains what that means, why it exists, and why it's considered one of the most important security decisions in the whole system.
Picture a shopping mall where, instead of every single store building its own separate security checkpoint, all shoppers pass through one central security desk staffed by trained guards before entering any store. The stores never touch your ID directly — they simply get a signal from the central desk saying “this person has been checked and cleared.” Keycloak’s hosted login page works on exactly this principle: rather than every application building its own login form and directly handling passwords, they all redirect users to one central, Keycloak-controlled page to log in. This guide walks through what that page actually is, how it works, and why it matters so much for security.
1What Is the Hosted Login Page?
The single most visible part of Keycloak, and one of its most important design decisions.
The Keycloak-hosted login page is the actual web page — rendered and served directly by Keycloak itself — where users type their username and password (or use another login method) to authenticate. When an application wants a user to log in, it doesn’t display its own login form. Instead, it redirects the user’s browser away to a page that Keycloak controls, hosted on Keycloak’s own server, styled with Keycloak’s own theme.
Think of paying for something online through a trusted payment processor. When you check out on a small online store, you’re often redirected to the payment provider’s own secure page to enter your card details — the store itself never sees or touches your card number. The hosted login page works the same way for passwords: the application redirects you to Keycloak’s own page, and Keycloak — not the application — is the only party that ever sees your actual credentials.
This single idea — that the application never directly handles the user’s password — is the foundation almost everything else in this guide builds on.
Centrally Controlled
The page lives on Keycloak’s server, not inside any individual application’s codebase.
Realm-Specific
Each realm has its own version of this page, with its own branding and login rules.
Reached By Redirect
Users are sent to it via a full browser redirect, not loaded quietly inside the application itself.
Customizable Appearance
Its look and feel can be restyled through Keycloak’s theming system to match an organization’s branding.
“Hosted” simply means the login page’s code, rendering, and handling of credentials all happen on Keycloak’s side — never inside the application asking for the login.
2Hosted Login vs. Embedded Login Forms
Two very different ways applications can ask users to log in — and why they’re not interchangeable.
Before Keycloak-style hosted pages became standard practice, many applications simply built their own login form directly inside the app and sent the typed password to their own backend to check. This is called an embedded login form, and understanding the contrast with hosted login explains why the industry moved away from it.
An embedded login form is like handing your passport directly to a store clerk who isn’t actually trained in passport verification, just because the store happened to build a booth that looks official. A hosted login page is like being sent to the actual passport control desk staffed by trained officers — the verification happens in the one place built and trusted specifically for that job.
| Aspect | Embedded Login Form | Keycloak-Hosted Login Page |
|---|---|---|
| Where the password is typed | Directly inside the application’s own page | On a separate page served by Keycloak |
| Who sees the raw password | The application’s own code | Only Keycloak itself |
| Consistency across apps | Each app looks and behaves differently | Same trusted flow reused by every app |
| Effort to add MFA or new methods | Must be built separately per application | Configured once in Keycloak, used everywhere |
The moment an application’s own code directly handles a raw password, that application becomes a new place where a mistake, bug, or breach could expose credentials. The hosted login page exists specifically to remove that risk from every application that uses it.
3What Makes Up the Hosted Login Page
The page isn’t just a static form — it’s assembled from several configurable pieces.
Login Theme
The visual styling — colors, logo, layout — applied to the hosted page, configurable per realm.
Authentication Flow
The ordered sequence of steps the page walks the user through — password entry, MFA prompt, terms acceptance.
Identity Provider Buttons
Optional “Sign in with Google” style buttons shown on the page when external identity providers are configured for the realm.
Realm Branding Settings
Realm-level display name, supported languages, and other presentation details shown on the page.
Think of the hosted login page like a hotel check-in counter that a franchise brand allows each individual hotel to slightly restyle — different colors, different logo — while the actual check-in procedure, security checks, and systems behind the counter stay exactly the same everywhere.
Because the login theme is separate from the authentication flow, organizations can make the page look completely custom to match their brand without touching, weakening, or reimplementing any of the actual security logic underneath.
4How the Hosted Login Page Works Internally
Tracing exactly what happens between clicking “Log In” and landing back inside the application.
The Application Redirects the Browser
Instead of showing its own form, the app sends the user’s entire browser to Keycloak’s login address for the correct realm.
Keycloak Renders the Hosted Login Page
Keycloak serves its own page, styled by the realm’s theme, showing whatever authentication steps the realm’s flow requires.
The User Authenticates Directly With Keycloak
Credentials are typed and submitted straight to Keycloak — the originating application never sees them at any point.
Keycloak Redirects Back With a Proof of Login
Once authentication succeeds, Keycloak sends the browser back to the application, carrying a short-lived code rather than the credentials themselves.
The Application Exchanges That Code for a Token
The application privately contacts Keycloak to trade that code for an actual access token, completing the login.
sequenceDiagram
participant U as User's Browser
participant App as Application
participant K as Keycloak Hosted Login Page
App->>U: Redirect to Keycloak login URL
U->>K: Browser loads hosted login page
U->>K: Submit credentials directly to Keycloak
K-->>U: Redirect back to app with a short-lived code
U->>App: Deliver the code
App->>K: Exchange code for access token (server-to-server)
K-->>App: Return access token
Notice that the application receives a temporary code, not the password, and even that code gets exchanged for the final token through a separate, private server-to-server step — keeping sensitive material out of the user’s visible browser history as much as possible.
5Customizing the Hosted Login Page
Keycloak’s theming system lets the page match an organization’s brand without weakening its security.
Login Theme
Controls the appearance of the login, registration, and password-reset pages users see before authenticating.
Account Theme
Styles the self-service page where logged-in users can manage their own profile and sessions.
Email Theme
Governs the look of emails Keycloak sends, such as password reset or account verification messages.
Admin Console Theme
Styles the separate administrative interface used to manage realms — distinct from the end-user login page.
Matching Company Branding
A business can replace Keycloak’s default look with its own logo, colors, and fonts on the login theme, so the login experience feels like a natural part of the product rather than a jarring jump to an unfamiliar page.
Multi-Language Support
The hosted login page can present different languages depending on the realm’s configured locales, letting one page serve a genuinely international user base without separate custom builds per language.
Theming changes appearance, not the underlying authentication logic. Teams should resist the temptation to bypass the hosted page’s flow entirely just to achieve a more “seamless” look — doing so usually reintroduces the very risks the hosted page was designed to avoid.
6The Authorization Code Exchange in Detail
A closer look at why the “code, then token” pattern matters so much.
The hosted login flow relies on a widely used standard called the Authorization Code flow, part of the OAuth 2.0 family of standards. Its defining feature is a deliberate two-step handoff: the browser only ever carries a short-lived, single-use code, while the actual access token is fetched separately, directly between the application’s backend and Keycloak.
flowchart LR
A[User Redirected to Hosted Login Page] --> B[Credentials Submitted to Keycloak]
B --> C[Keycloak Issues Short-Lived Code]
C --> D[Browser Carries Code Back to App]
D --> E[App Backend Exchanges Code for Token]
E --> F[Access Token Used for Future Requests]
It’s similar to a coat check at a theater. You don’t carry your actual coat around with you all evening — you get a small numbered ticket. Only when you present that ticket at the counter, out of the crowd’s view, do you actually receive the coat back. The code is the ticket; the access token is the coat; the “counter” is the private server-to-server exchange.
Because the code is short-lived and can only be used once, even if it were somehow intercepted in the browser’s address bar, it would already be useless to an attacker by the time they tried to reuse it.
7Security Advantages of a Hosted Login Page
Why this design choice is considered a security best practice rather than just a convenience.
Applications Never Touch Passwords
Credentials are typed only into Keycloak’s own page, drastically shrinking the number of places a password could ever leak from.
Consistent Security Upgrades
Adding MFA, passkeys, or new login methods happens once inside Keycloak and instantly applies to every connected application.
Reduced Phishing Surface
Users learn to recognize one consistent, trusted login page rather than a different, easily-spoofed form inside every individual app.
Strict Redirect Validation
Keycloak only sends users back to pre-registered, approved application addresses, preventing malicious apps from silently harvesting login codes.
Because the application never sees the raw credential, common risks like an application accidentally logging passwords, storing them insecurely, or leaking them through a coding bug are removed entirely from that application’s responsibility.
8Design Patterns and Anti-Patterns
Lessons learned from teams who tried to shortcut the hosted login model.
Problem
Building a custom login form inside the application and sending the raw username and password directly to Keycloak’s backend, bypassing the hosted page entirely.
Why It’s Harmful
This reintroduces exactly the risk the hosted page was designed to eliminate — the application’s own code now directly handles raw credentials, and every security improvement made to Keycloak’s page (like new MFA methods) has to be manually rebuilt inside that custom form too.
Correct Approach
Always redirect users to the hosted login page for the standard authorization code flow, reserving direct credential exchange only for very specific, carefully justified cases such as trusted first-party command-line tools.
Problem
Loading the hosted login page inside a hidden iframe within the application to make the redirect less visible to users.
Why It’s Harmful
Modern browsers increasingly restrict third-party content inside iframes for privacy and security reasons, and hiding the login page undermines the very trust signal — a recognizable, full-page login screen — that helps users spot phishing attempts.
Correct Approach
Use a full-page browser redirect (or the platform’s equivalent, such as a system browser view on mobile) so users can clearly see and trust that they are on Keycloak’s genuine login page.
Design Pattern: One Hosted Page, Many Applications
Every application within a realm redirecting to the same hosted login page means users experience one consistent, learnable login process across an entire product ecosystem, rather than a different form to second-guess in every app.
9Best Practices and Common Mistakes
Practical guidance for teams integrating with the hosted login page.
Always Use the Standard Redirect Flow
Let Keycloak’s hosted page handle the actual login rather than trying to replicate it inside the application.
Register Exact, Trusted Redirect Addresses
Only allow Keycloak to send users back to precise, known application URLs, closing off a common trick attackers try to exploit.
Customize the Theme, Not the Flow
Restyle the hosted page freely for branding, but leave the underlying authentication steps and validation logic untouched.
Test the Full Redirect Journey, Not Just the Form
Verify the entire path — redirect out, login, redirect back, and token exchange — works correctly, not just that the page renders.
Common missteps include registering overly broad or wildcard redirect addresses, embedding the login page in ways that hide it from users, and assuming a custom-built login form is “just as secure” simply because it looks similar to the hosted page.
10Advantages and Disadvantages of Hosted Login
A fair look at the trade-offs, since even a security best practice has costs.
Advantages
- Applications never handle raw passwords, shrinking overall attack surface
- New login methods and MFA roll out to every app at once
- One consistent, learnable login experience across a product ecosystem
- Strict redirect-address validation closes off a common attack vector
Disadvantages / Trade-offs
- The visible redirect away from the app can feel less seamless to some users
- Deep branding customization requires learning Keycloak’s theming system
- Mobile apps need a system browser view rather than a simple in-app form, which takes extra setup
The brief visual interruption of a redirect is a small, well-understood cost compared to the ongoing risk of every application independently handling raw passwords — which is why hosted login pages have become the standard pattern across the industry.
11Monitoring and Logging Login Activity
Because every login funnels through one hosted page, visibility becomes simpler, not harder.
Centralized Login Event Logs
Because every application funnels through the same hosted page, all login successes and failures are recorded in one consistent place rather than scattered across separate app logs.
Failed-Login Pattern Detection
Spikes in failed attempts on the hosted page across many accounts can be spotted quickly, since the data isn’t fragmented across different login implementations.
Redirect and Token-Exchange Auditing
Logging both halves of the code-for-token exchange helps confirm the full flow completed correctly and wasn’t interrupted or tampered with.
12Real-World and Industry Examples
The hosted login pattern in action across different kinds of software.
Internal Enterprise Tool Suites
A company running dozens of internal web applications can point every single one at the same Keycloak-hosted login page, giving employees one familiar, trusted login screen no matter which internal tool they’re opening.
Multi-Product SaaS Platforms
A vendor with several distinct products under one account system uses the hosted page so a customer logs in once, in one consistent place, regardless of which product they started from.
Mobile Applications
Rather than embedding a login form inside the app itself, mobile apps commonly open the hosted login page in a secure system browser view, keeping the same password-isolation guarantees as a web application.
Partner and Vendor Portals
Organizations exposing tools to external partners often rely on the hosted page’s redirect-address validation to ensure logins can only ever return to explicitly approved partner systems.
13Frequently Asked Questions
This is the hosted login pattern at work — the application is intentionally sending you to Keycloak’s own page so that your password is only ever typed into a system built and trusted specifically for handling it.
Yes — through Keycloak’s login theme, the page’s colors, logo, and layout can be customized to closely match an application’s branding, even though the underlying page and its security logic remain separate.
No. Credentials are submitted directly from the hosted login page to Keycloak. The application only ever receives a short-lived code, which it later exchanges for an access token through a separate, private step.
Technically yes, through a direct credential exchange, but this is generally discouraged because it puts the application back in the business of handling raw passwords — undoing the main benefit of the hosted approach.
A visible, full-page redirect is a deliberate security and trust signal, letting users clearly verify they’re on the genuine login page rather than something hidden or potentially spoofed inside another site.
Often not — because they share the same hosted login page and realm, Keycloak can recognize an existing valid session and skip straight back to the application without asking for credentials again, a behavior known as single sign-on.
14Summary and Key Takeaways
The Keycloak-hosted login page is the central, trusted screen every connected application redirects users to for authentication, rather than each application building and handling its own login form. By keeping raw credentials confined entirely to Keycloak’s own page, and passing only short-lived codes back to applications, this design dramatically reduces the number of places a password could ever be exposed — while still giving organizations full control over branding through Keycloak’s theming system.
Key Takeaways
- The hosted login page is served entirely by Keycloak — applications redirect users to it rather than collecting credentials themselves.
- Applications never see raw passwords, only a short-lived code that’s later exchanged for a token behind the scenes.
- Theming changes appearance, not security logic — organizations can fully rebrand the page without touching how authentication actually works.
- The Authorization Code flow’s two-step handoff keeps sensitive tokens out of the browser’s visible address bar.
- Strict redirect-address validation ensures Keycloak only ever sends users back to explicitly approved applications.
- Bypassing the hosted page reintroduces the exact risks it was built to remove — it should be avoided outside very specific, justified cases.
- Shared use of the same hosted page across applications is what makes single sign-on and consistent security upgrades possible.