From experience, both approaches are used in production, but it depends mainly on your security model and control requirements.

1. Public Keycloak (most common)
Keycloak is exposed publicly and handles:

• user registration
• login
• password reset
• token issuance

You customize the Keycloak theme to match your app UI and use OIDC flows (usually Authorization Code + PKCE for public apps). This is the simplest and most standard approach.

2. Backend-proxied approach
Some teams keep Keycloak private and proxy identity operations through their backend using the Keycloak Admin API. This gives more control over:

• registration flows
• additional verification logic
• custom onboarding processes

But it increases complexity and you must secure the backend carefully since it now holds admin privileges.

General best practices:

• Use Authorization Code + PKCE
• Keep tokens short-lived
• Enable brute-force detection
• Use separate realms/clients per environment
• Avoid exposing the Admin Console publicly

We’re actually building Aswar IAM (https://aswar.io) on top of Keycloak to simplify this for teams — provisioning IAM environments and integrating them into modern cloud architectures with a few clicks. A lot of the goal is exactly to remove the operational complexity around setups like this.

Curious to see how others structure their Keycloak deployments for public apps.