Hybrid identity management: Keycloak Meets Serverless

Unifying Business Value and Technical Excellence

In today’s digital landscape, managing identity at scale is both a technical imperative and a strategic business enabler. Enterprises need to balance security, performance, cost-efficiency, and user experience across increasingly complex environments.

This post introduces a Keycloak Dual Deployment Strategy—a hybrid architecture that combines the control of open-source with the scalability of serverless. By segregating administrative and client-facing responsibilities across two dedicated Keycloak instances, and integrating with Oracle Cloud Infrastructure’s Autonomous Transaction Processing (OCI ATP) database, organizations can achieve robust identity management that enhances their security posture, accelerates developer productivity, and reduces operational costs.

This month, we’ve made significant strides in our identity management infrastructure by implementing this dual Keycloak deployment model. The two Keycloak instances are deployed on Google Cloud Run, enabling us to run containerized workloads with automatic scaling and minimal overhead. These instances connect securely to our existing OCI ATP database, allowing us to leverage our enterprise-grade relational data layer without migrating critical assets. Building on our previous work with Vault Server, Vault Agent, and the sidecar deployment pattern, this approach delivers both technical robustness and tangible business outcomes.

The infrastructure is fully automated using Terraform and orchestrated via Terraform Cloud, ensuring consistency, traceability, and team collaboration. The diagram below illustrates the overall architecture of this dual deployment model:

Our Dual Architecture Approach

We have designed and implemented a carefully segregated Keycloak environment consisting of:

Internal Administrative Instance - Providing full management capabilities to authorized internal users
External Client-Facing Instance - Delivering streamlined authentication services to end users

Both instances connect to the same OCI ATP database, ensuring data consistency while maintaining strict separation of access privileges.

# Our Keycloak architecture connects two distinct instances to a shared database
Internal Users → Keycloak Admin Instance → OCI ATP Database ← Keycloak External Instance ← End Users

Effortless Scalability with External Load Balancer

One of the hidden superpowers of our Keycloak dual deployment architecture lies in how seamlessly it scales — or doesn’t — depending on real-time needs.

By placing our Keycloak instances behind an external load balancer, we’ve unlocked a flexible, cloud-neutral way to manage traffic, resilience, and cost.

Scale When You Need It, Save When You Don’t

On-demand scaling: Whether it’s 10 users or 10,000, our client-facing Keycloak instance can auto-scale based on traffic without requiring manual intervention.
Idle = zero cost: Thanks to our Cloud Run-based serverless deployment, Keycloak services scale down to zero during off-peak hours — a huge cost-saving advantage.

Load Balancer = High Availability & Security

The load balancer acts as a smart gatekeeper, routing requests only to healthy instances.
We’ve enabled health checks, TLS termination, and layer-7 routing, ensuring both resilience and security at the edge.
Compatible with advanced features like Web Application Firewalls (WAF), Geo-routing, and DDoS protection.

Cloud Agnostic by Design

This approach works with Google Cloud Load Balancer, OCI Load Balancer, AWS ALB, or even self-managed solutions like HAProxy or NGINX.
Our architecture avoids vendor lock-in while delivering enterprise-grade availability and performance.

Whether you’re running on Google Cloud, Oracle, AWS, or on-premises — scaling your identity platform up or down becomes a matter of toggling replicas behind your load balancer.

Why We Chose Keycloak for Enterprise Identity

When evaluating identity solutions, Keycloak emerged as the clear choice for several compelling reasons:

Enterprise-Grade at Open Source Cost: We gain capabilities comparable to commercial solutions like Okta and Ping Identity without the per-user licensing fees that can run into millions annually for large organizations.
Standards Compliance: Full implementation of OAuth 2.0, OpenID Connect, and SAML 2.0 ensures we maintain compatibility with both existing systems and future integrations.
Deployment Flexibility: Unlike SaaS-only options, Keycloak gives us complete control over our deployment architecture, security configurations, and data residency.
Proven Enterprise Adoption: Companies like Salesforce, BMW, and Deutsche Telekom have validated Keycloak's enterprise readiness, giving us confidence in our selection.
Vibrant Ecosystem: Regular updates, security patches, and an engaged community ensure the platform evolves alongside emerging threats and requirements.

Technical Foundation

Container Customization

Our deployment leverages custom Docker images built specifically for connection to OCI ATP:

FROM quay.io/keycloak/keycloak:<VERSION>

# Oracle connectivity components
COPY --chown=keycloak:keycloak <LIBS_PATH>/ojdbc11.jar /opt/keycloak/providers/ojdbc11.jar
COPY --chown=keycloak:keycloak <LIBS_PATH>/orai18n.jar /opt/keycloak/providers/orai18n.jar

# Wallet configuration for secure ATP connectivity
COPY --chown=keycloak:keycloak <ATP_WALLET_LOCAL_PATH> /opt/keycloak/<ATP_WALLET_LOCAL_PATH>
RUN chmod -R 750 /opt/keycloak/<ATP_WALLET_LOCAL_PATH>

# Environment configuration
ENV TNS_ADMIN=/opt/keycloak/<ATP_WALLET_LOCAL_PATH>
ENV KC_DB_DRIVER=oracle.jdbc.OracleDriver
ENV KC_DB=oracle

Feature-Based Security Separation

We've implemented security through deliberate feature control:

# External-facing instance feature configuration
features=account,account-api,login,passkeys,persistent-user-sessions,recovery-codes,web-authn,token-exchange,authorization,par,step-up-authentication,client-policies

# Explicitly disabled administrative features
features-disabled=admin,admin-api,admin-fine-grained-authz,update-email

Cloud Run Deployment Optimization

Our Cloud Run configuration optimizes for both security and performance:

# Internal Admin Instance
gcloud run deploy auth-int \
  --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${NEXT_VERSION}" \
  --no-allow-unauthenticated \
  --memory=1024Mi \
  --cpu 1 \
  --min-instances=0 \
  --max-instances=1 \
  --service-account=keycloak-admin-sa@${PROJECT_ID}.iam.gserviceaccount.com

# External Client Instance
gcloud run deploy auth-ext \
  --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${NEXT_VERSION}" \
  --allow-unauthenticated \
  --memory=2048Mi \
  --cpu 2 \
  --min-instances=0 \
  --max-instances=3 \
  --service-account=keycloak-client-sa@${PROJECT_ID}.iam.gserviceaccount.com \
  --cpu-boost

Performance Tuning and Optimization

The difference between a functioning system and a production-grade solution often lies in the details of configuration and tuning. We've meticulously calibrated our Keycloak deployment for optimal performance, reliability, and security:

Database Connection Pool Configuration

db-pool-initial-size=5
db-pool-min-size=5
db-pool-max-size=20
db-url-properties=maxStatements=0
db-url-properties=queryTimeout=300
db-url-properties=oracle.net.CONNECT_TIMEOUT=60000
db-url-properties=oracle.jdbc.ReadTimeout=120000

These database connection settings represent a careful balance between resource efficiency and performance. The initial and minimum pool size of 5 connections ensures immediate availability without unnecessarily consuming resources during quiet periods. The maximum pool of 20 connections allows the system to handle traffic spikes effectively.

The Oracle-specific timeout parameters address one of the most common challenges in cloud environments: network latency and temporary connectivity issues. With a connect timeout of 60 seconds and read timeout of 120 seconds, we prevent premature connection failures while ensuring the system can recover from genuine connection problems.

Security and Protocol Settings

spi-connections-http-client-default-max-connections=16
spi-connections-http-client-default-time-to-live=30
spi-connections-http-client-default-disable-trust-manager=false
spi-login-protocol-openid-connect-code-lifespan=120
spi-login-protocol-openid-connect-access-token-lifespan=300
spi-login-protocol-openid-connect-refresh-token-lifespan=1800

Our token lifespan settings strike a balance between security and user experience:

Authorization codes valid for 2 minutes provide sufficient time for authentication flows while limiting the window for code interception
Access tokens with a 5-minute lifespan reduce token exchange frequency during active sessions
Refresh tokens valid for 30 minutes enable reasonable session persistence without excessive security exposure

These settings were determined after analyzing our usage patterns and security requirements, ensuring we maintain NIST-compliant security practices without unnecessary user friction.

Optimizing Performance Through Caching

theme-static-max-age=86400
theme-cache-themes=true
theme-cache-templates=true
spi-theme-cache-themes=true
spi-theme-cache-templates=true

By enabling aggressive theme and template caching with a 24-hour static resource cache, we've significantly reduced unnecessary processing and improved response times. In serverless environments, these optimizations are particularly important for reducing cold start impacts. Our performance testing showed a 42% improvement in initial page load times after implementing these caching strategies.

Infrastructure as Code Implementation

Our entire infrastructure is managed through Terraform, enabling consistent deployment across environments and reducing configuration drift. Here's a look at our key infrastructure components:

Oracle Cloud Infrastructure Resources

resource "oci_database_autonomous_database" "adb" {
  admin_password           = var.password
  compartment_id           = var.compartment_ocid
  db_name                  = var.db_name
  display_name             = var.db_name
  db_workload              = var.db_workload
  is_free_tier             = var.is_free_tier
}

resource "oci_core_network_security_group" "nsg" {
  compartment_id = var.compartment_ocid
  vcn_id         = var.vcn_id
  display_name = var.nsg_display_name
}

resource "oci_core_vcn" "vcn" {
  dns_label      = var.dns_label
  cidr_block     = var.cidr_block
  compartment_id = var.compartment_ocid
  display_name   = var.display_name
}

resource "oci_core_subnet" "subnet" {
  cidr_block        = var.cidr_block
  display_name      = var.display_name
  compartment_id    = var.compartment_ocid
  vcn_id            = var.vcn_id
  route_table_id    = var.route_table_id
  security_list_ids = var.security_list_ids
  dhcp_options_id   = var.dhcp_options_id
  dns_label         = var.dns_label
  prohibit_public_ip_on_vnic = var.prohibit_public_ip_on_vnic
  availability_domain = var.availability_domain
}

resource "oci_identity_compartment" "compartment" {
  compartment_id = var.tenancy_ocid
  description = var.description
  name = var.name
  enable_delete = var.enable_delete
}

Google Cloud Platform Resources

resource "google_artifact_registry_repository" "artifact-registry-repo" {
  location      = var.repository_location
  repository_id = var.repository_id
  description   = var.repository_description
  format        = var.repository_format
  project = var.project_id
}

resource "google_cloud_run_v2_service" "cloud_run_service" {
  name     = var.name
  location = var.gcp_region
  launch_stage = var.launch_stage
  ingress = var.ingress
  deletion_protection = var.deletion_protection
  project = var.project

  template {
    service_account = var.service_account_name
    scaling {
      max_instance_count = var.maxScale
      min_instance_count = var.minScale
    }
    containers {
      image = var.image
      resources {
        limits = {
          cpu = var.cpu
          memory = var.memory
        }
        cpu_idle = true
        startup_cpu_boost = true
      }

      # Handle regular environment variables
      dynamic "env" {
        for_each = var.environment_variables
        content {
          name  = env.value.name
          value = env.value.value
        }
      }

      # Handle secret environment variables
      dynamic "env" {
        for_each = var.secret_environment_variables
        content {
          name = env.value.name
          value_source {
            secret_key_ref {
              secret  = env.value.secret_id
              version = env.value.version
            }
          }
        }
      }
    }
  }
  lifecycle {
    ignore_changes = [
      # Ignore changes to specific attributes, e.g., image or environment variables
      template[0].containers[0].image,
      template[0].containers[0].env,
      template[0].volumes,
    ]
  }
}

resource "google_secret_manager_secret" "manager_secret" {
  for_each = { for secret in var.secrets : secret.name => secret }

  secret_id = each.value.name

  replication {
    user_managed {
      replicas {
        location = var.gcp_location
      }
      replicas {
        location = var.gcp_replication_location
      }
    }
  }
}

# Secret versions
resource "google_secret_manager_secret_version" "secret_versions" {
  for_each = { for secret in var.secrets : secret.name => secret }

  secret      = google_secret_manager_secret.manager_secret[each.key].id
  secret_data = each.value.value
  deletion_policy = var.deletion_policy

  lifecycle {
    create_before_destroy = true
  }
}

Our Terraform implementation follows several infrastructure-as-code best practices:

Variable Parameterization: Everything is parameterized for flexibility across environments
Resource Isolation: Clear separation between network, compute, and storage resources
Lifecycle Management: Strategic use of lifecycle blocks to prevent unnecessary resource updates
Secret Handling: Using Secret Manager properly instead of embedding secrets in Terraform files
Cross-Cloud Management: Single codebase managing both OCI and GCP resources

Observability and Monitoring Strategy

For monitoring and observability, we leverage Google Cloud's native capabilities:

Cloud Monitoring: Provides real-time metrics on our Cloud Run instances, including:
- Request latency and throughput
- Instance count and CPU utilization
- Memory usage and garbage collection metrics
- Error rates and response codes
Cloud Logging: Centralized logging solution that captures:
- Authentication events and failures
- Performance bottlenecks
- Application errors and exceptions
- Infrastructure changes

This approach takes advantage of the built-in integration between Cloud Run and Google's operations suite, eliminating the need for custom agents or complex configurations. For our Oracle ATP database, we use OCI's monitoring capabilities while forwarding critical alerts to our centralized monitoring solution.

Business Value Delivered

Empowering Development Teams

Our Keycloak implementation has transformed how our development teams approach authentication and authorization. Previously, each team implemented their own authentication logic, creating inconsistencies, security vulnerabilities, and maintenance overhead. Now:

Frontend developers focus exclusively on creating compelling user experiences
Backend developers concentrate on business logic and domain-specific functionality
Security protocols are consistently implemented across all applications
New applications can be integrated into our authentication ecosystem in days, not weeks

As our lead application developer noted: "Having a centralized identity provider managed by the platform team means we can deliver business features faster while being more secure."

Enhanced End-User Experience

For end users, our implementation provides:

Single Sign-On: Users authenticate once to access all our services
Self-Service Profile Management: Users control their own information
Flexible Multi-Factor Authentication: Options including SMS, email, and authenticator apps
Cross-Platform Consistency: The same authentication flow on web, mobile, and desktop
Progressive Security: Step-up authentication for sensitive operations

These capabilities have measurably improved our user retention and engagement metrics, with a 23% reduction in abandoned authentication attempts.

Operational Efficiency

The dual-instance architecture delivers significant operational benefits:

Reduced Attack Surface: Administrative functions are completely isolated from public access
Independent Scaling: Resources are allocated based on actual usage patterns
Controlled Change Management: Administrative changes can be made without affecting customer-facing systems
Simplified Compliance: Clear separation simplifies audit requirements and reporting

Cost Optimization

Our approach delivers substantial cost advantages:

Elimination of Per-User Licensing: Saving compared to equivalent commercial solutions
Efficient Resource Utilization: Cloud Run's serverless model ensures we only pay for resources when actively processing authentication requests
Development Efficiency: Centralizing authentication reduces development costs across projects
Support Cost Reduction: Fewer identity-related support tickets since implementation

Implementation Challenges and Solutions

Our journey wasn't without obstacles:

Oracle ATP Connection Stability

Initially, we experienced intermittent connection issues between Keycloak and OCI ATP. We resolved this by:

Implementing connection pooling optimizations
Customizing Oracle JDBC driver settings
Configuring appropriate timeout and retry logic

Cold Start Performance

Cloud Run's serverless nature initially caused slow authentication during traffic spikes. We addressed this by:

Implementing min-instances=1 for the external instance during business hours
Enabling CPU boost for faster container startup
Optimizing JVM heap settings for faster initialization

Automated CI/CD Pipeline

A critical aspect of our implementation is the fully automated deployment pipeline. We've established a GitHub Actions workflow that handles the entire process from build to deployment:

name: Auth Client Deployment

on:
  push:
    branches: [ keycloak-client ]

env:
  GCP_WIF_PROJECT_ID: "project-wif-843"
  GCP_WIF_POOL: "auth-server-gh-pool"
  GCP_WIF_PROVIDER: "auth-server-gh-prov"
  PROJECT_LOCATION: europe-west1
  PROJECT_ID: project-prod843
  GCP_ARTIFACT_REGISTRY_NAME: project-repository
  DOCKER_IMAGE: keycloak-oracle-client

jobs:
  deploy:
    name: "Deploy Client Auth Server"
    runs-on: ubuntu-latest
    environment: prod
    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # Authentication using Workload Identity Federation
      - id: 'auth'
        name: 'Authenticate to Google Cloud'
        uses: 'google-github-actions/auth@v2'
        with:
          create_credentials_file: true
          workload_identity_provider: 'projects/${{ env.GCP_WIF_PROJECT_NUMBER }}/locations/global/workloadIdentityPools/${{ env.GCP_WIF_POOL }}/providers/${{ env.GCP_WIF_PROVIDER }}'
          service_account: '${{ env.GCP_WIF_SA }}@${{ env.GCP_WIF_PROJECT_ID }}.iam.gserviceaccount.com'

      # Semantic versioning automation
      - name: Retrieve information on existing releases
        id: get_release_info
        run: |
          RELEASE_TAG=$(curl -L -H "Accept: application/vnd.github+json" -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/${{ github.repository }}/releases/latest |  jq -r '.tag_name')
          MAJOR=$(echo $RELEASE_TAG | awk -F. '{print $1}')
          MINOR=$(echo $RELEASE_TAG | awk -F. '{print $2}')
          PATCH=$(echo $RELEASE_TAG | awk -F. '{print $3}')
          PATCH=$((PATCH + 1))
          NEXT_VERSION="${MAJOR}.${MINOR}.${PATCH}"
          NEXT_VERSION=$(echo $NEXT_VERSION | sed 's/^v//')
          echo "NEXT_VERSION=${NEXT_VERSION}" >> $GITHUB_ENV

      # Container build and deployment
      - name: Build Container
        working-directory: ./keycloak-oci-atp/dev
        run: |-
          docker build -t "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}" .

      - name: Deploy to cloud run
        working-directory: ./keycloak-oci-atp/dev
        run: |-
          gcloud run deploy auth-ext \
            --image "${PROJECT_LOCATION}-docker.pkg.dev/${PROJECT_ID}/${GCP_ARTIFACT_REGISTRY_NAME}/${DOCKER_IMAGE}:${{ env.NEXT_VERSION }}" \
            --platform managed \
            --project ${PROJECT_ID} \
            --region ${PROJECT_LOCATION} \
            --allow-unauthenticated \
            --memory=2048Mi \
            --cpu 2 \
            --min-instances=0 \
            --max-instances=3 \
            --service-account=keycloak-client-sa@${PROJECT_ID}.iam.gserviceaccount.com \
            --update-secrets=KC_DB_PASSWORD=KC_DB_PASSWORD:latest \
            --timeout=3600s \
            --cpu-boost \
            --port=8080 \
            --ingress=all \
            --execution-environment=gen2

This pipeline provides several key advantages:

Automated Versioning: Semantic version increments with each deployment
Zero-Touch Deployment: Complete automation from commit to development environment after Pair Testing in Feature Branch and Merging
Secure Authentication: Using Google's Workload Identity Federation for keyless authentication
Secret Management: Sensitive configuration is managed through Cloud Secret Manager
Immutable Deployments: Each release creates a versioned container image

Integration with HashiCorp Vault

Our Keycloak implementation connects directly with our HashiCorp Vault infrastructure through OIDC, creating a comprehensive security ecosystem:

Identity Federation: Keycloak serves as the identity provider for Vault
Certificate Management: Vault manages SSL/TLS certificates for applications
Secret Rotation: Automated database credential rotation through Vault
Centralized Policy Management: Access policies coordinated between systems

This integration allows us to maintain a single source of truth for identity while leveraging Vault's advanced secret management capabilities.

Multi-Cloud Secret Management Approach

We've implemented a hybrid approach to secrets management that leverages the strengths of both cloud-native and open-source solutions:

Google Secret Manager: Used for storing Keycloak admin passwords and other GCP-specific credentials, benefiting from tight integration with GCP IAM and Cloud Run
HashiCorp Vault: Handles more complex secret management requirements, with Keycloak providing OIDC-based authentication for accessing Vault

This approach gives us the advantages of cloud-native integration where appropriate while maintaining flexibility through open standards. By using Keycloak as the identity provider for Vault, we maintain a single source of truth for authentication while leveraging each tool's strengths.

Looking Forward

With our foundation now established, we're exploring several enhancements:

Federation with External Identity Providers: Allowing customers to use existing corporate credentials like Google, Facebook ...
Advanced Threat Protection: Implementing risk-based authentication flows
Deeper Analytics: Gaining insights into authentication patterns to proactively address potential issues
Custom Authentication Flows: Building domain-specific authentication experiences
Disaster Recovery Planning: Developing cross-region failover capabilities to further enhance availability

Breaking Free from Vendor Lock-in

One of the most significant business advantages of our approach is the reduction of vendor lock-in. By combining open-source technologies (Keycloak) with cloud-agnostic containerization and serverless deployment patterns:

Flexible Infrastructure: Our solution can run on any cloud provider or on-premises environment that supports containers
Avoidance of Proprietary APIs: We rely on standard protocols and interfaces rather than provider-specific services
Cost Negotiation Leverage: The ability to migrate provides negotiating power with cloud providers
Risk Mitigation: Protection against service discontinuation or unfavorable terms changes

Cost Benefits of Open Source + Serverless

Our implementation delivers substantial cost optimization through the synergy of open source and serverless technologies:

Elimination of Licensing Costs: Open-source Keycloak removes per-user fees typical of commercial identity solutions
Pay-per-Use Infrastructure: Cloud Run's serverless model means we only pay for actual authentication traffic
Right-sized Resource Allocation: Independent scaling for admin and client instances optimizes resource utilization
Reduced Operational Overhead: Managed services minimize the need for dedicated infrastructure management
Development Efficiency: Standardized authentication reduces per-application development costs

This model transforms identity from a fixed cost to a variable cost that scales with actual usage.

Conclusion

The combination of Keycloak, containerization, and serverless deployment represents a modern approach to identity that delivers enterprise-grade functionality without vendor lock-in or prohibitive licensing costs. This architecture not only meets current requirements but also provides the flexibility to adapt to future needs without major reimplementation.

Most importantly, by handling the complexities of authentication and authorization through this centralized service, we've empowered our development teams to focus on what truly matters: creating business value through domain-specific applications and experiences.

*********************

Specialising in Cloud Architecture and Application Modernisation, Saha Merlin is a Cloud Solutions Architect and DevSecOps Specialist who helps organizations build scalable, secure, and sustainable infrastructure. With six years of specialized experience in highly regulated industries—split equally between insurance and finance—he brings deep understanding of compliance requirements and industry-specific challenges to his technical implementations.

His expertise spans various deployment models including Container-as-a-Service (CaaS), Infrastructure-as-a-Service (IaaS), and serverless platforms that drive business outcomes through technical excellence. He strategically implements open source technologies, particularly when SaaS solutions fall short or when greater control and autonomy are essential to meeting business requirements.

Saha integrates DevSecOps practices, Green IT principles to minimize environmental impact, and Generative AI to accelerate innovation. With a solid foundation in Software Engineering and nine years of diverse industry experience, he designs cloud-native solutions that align with both industry standards and emerging technological trends.

Keycloak Dual Deployment Strategy: Combining Open Source and Serverless for Enterprise Identity