OpenGate/ Docs

Architecture Overview

OpenGate IAM is designed as a true microservices architecture — each service owns its own database, communicates asynchronously via Kafka, and is independently deployable.

On this page


System Diagram

Live System · Microservices

OpenGate IAM

Architecture Overview · True Microservices · Event-Driven

Client Layer
Client Applications
Browser · Mobile · Backend
SPANative AppServer-SideHTTPS :443
HTTPS :443
Proxy / CDN
Reverse Proxy
Nginx · Traefik · ALB
SSL TerminationLoad BalancingCDN
HTTP :8080
API Gateway
Spring Cloud Gateway · :8080
opengate-gateway
Single Entry Point · JWT Validation · CORS · Rate Limiting
CORS
Routing
Rate Limiting
Request Log
OAuth2 RS
Microservices
auth
Auth
:8081
user
User
:8082
realm
Realm
:8083
rbac
RBAC
:8084
client
Client
:8085
mfa
MFA
:8086
Persistence Layer
Cache
Redis
:6379
SessionsOTPsBlacklist
Database
PostgreSQL 16
_auth_user_realm_rbac_clients_notif
Event Stream
Message Bus
Apache Kafka
Event Stream · Async Communication
user.createdauth.login.successauth.login.failureauth.logoutsession.terminatedmfa.otp_sent
Consumers
session-service
Session
:8087
notification-service
Notification
:8088
Outputs
Email
SMTP Server
Notifications · Alerts
Management
Admin API
:8089
Design Principles
IsolationDB per Service
EntrySingle Gateway
ServicesStateless
ConsistencyEventual (Kafka)
TenancyMulti (Realms)
State Distribution
PostgreSQLEntities
RedisSessions · OTPs
RedisRate Counters
RedisToken Blacklist
KafkaAudit Trail
Security Model
GatewayJWT Validation
ServicespermitAll
Realm scopeJWT claim
DB queriesrealm_name pred
Auth RedisTTL codes/tokens

Design Principles

1. Database per Service

Each microservice has its own PostgreSQL database. No shared tables, no cross-service JOINs. Data consistency is maintained through eventual consistency via Kafka events.

ServiceDatabase
auth-serviceopengate_auth
user-serviceopengate_users
realm-serviceopengate_realms
rbac-serviceopengate_rbac
client-serviceopengate_clients
notification-serviceopengate_notifications

2. Gateway as Single Entry Point

All external traffic enters through the gateway on port 8080. Internal services are never exposed directly. The gateway handles CORS, routing, and request logging.

3. Stateless Services

All business logic services are stateless. State lives in:

  • PostgreSQL — persistent entities (users, roles, clients, realms)
  • Redis — ephemeral data (sessions, OTPs, rate limit counters, token blacklist)
  • Kafka — event stream (audit trail)

Event Topology

TopicProducerConsumers
user.createduser-servicenotification-service
user.email_verifieduser-service
auth.login.successauth-servicesession-service
auth.login.failureauth-servicenotification-service
auth.logoutauth-servicesession-service
session.terminatedsession-service
mfa.otp_sentmfa-service

Security Model

Request
  └─► Gateway (JWT validation via Spring Security OAuth2 Resource Server)
        └─► Service (SecurityConfig: permitAll — gateway already verified)

Auth service exception

The auth-service uses Redis to store authorization codes and refresh tokens with TTLs — it is the only service with a meaningful Redis write dependency.


Multi-Tenancy (Realms)

Every resource is scoped to a realmName. The realm is extracted from the JWT realm claim or from the URL path (/realms/{realm}/...). Realm isolation is enforced at the database query level — every repository query includes realmName as a predicate.

/realms/{realmName}/...
       │
       ▼
  JWT claim: realm = "acme-corp"
       │
       ▼
  Repository: WHERE realm_name = 'acme-corp'