MaxKey SSO Deep Dive: Enterprise Authentication Architecture, Security Mechanisms, and bcrypt Password Storage

This article explores MaxKey, an open-source single sign-on system supporting OAuth 2.x, OpenID Connect, SAML 2.0, JWT, CAS, and SCIM, detailing its microservices architecture, security features like secondary authentication and single logout, session timeout design, brute-force protections, and bcrypt password storage implementation.

Architect's Guide
Architect's Guide
Architect's Guide
MaxKey SSO Deep Dive: Enterprise Authentication Architecture, Security Mechanisms, and bcrypt Password Storage

Project Overview

MaxKey (a pun on "Marx's Key" meaning "maximum key") is an enterprise-grade single sign-on (SSO) authentication system. It supports standard protocols including OAuth 2.x/OpenID Connect, SAML 2.0, JWT, CAS, and SCIM, providing identity management (IDM), access management (AM), SSO, RBAC permission management, and resource management. The system emphasizes performance, security, and usability in enterprise scenarios across healthcare, finance, government, and manufacturing.

Core SSO Concepts

Single Sign-On (SSO) allows users to authenticate once at a central identity provider and access all trusted applications without re-login. Two key requirements: all applications share one identity authentication system, and all applications can recognize and extract ticket information.

Key Functional Features

Standard Authentication Protocols: OAuth 2.x/OpenID Connect, SAML 2.0, JWT, CAS, SCIM 2.0

Login & Integration: Standard auth interfaces for SSO integration, secure mobile access, API security, third-party and internet authentication consolidation

User Lifecycle Management: SCIM 2.0 support with out-of-the-box connectors for identity provisioning and synchronization

Directory Integration: Simplifies Microsoft Active Directory and standard LDAP server organization/account management; includes password self-service reset

IDaaS Multi-tenancy: Supports independent management for multiple enterprises under a group or data isolation for departments within an enterprise, reducing operational costs

Cross-platform Support: Platform-agnostic authentication center covering web, iOS, Android, and other mobile devices

Configurable Policies: Password policies, access policies; IP geolocation via Ip2region or GeoLite2; comprehensive security auditing (full lifecycle, access behavior traceability, compliance, risk alerting)

Technology Stack: Java EE platform, microservices architecture using Spring, MySQL, Tomcat, Redis, MQ; highly extensible

Open Source & Self-controlled: Open-source, secure, and independently controllable

System Security Mechanisms

Secondary Password Authentication

After initial SSO login, users can access applications directly via protocol tokens. For sensitive systems (e.g., financial systems, personal payroll), MaxKey enforces a second password verification when users click specific application icons. This protects against credential leakage scenarios such as work delegation; even if the primary SSO password is compromised, the secondary password safeguards critical applications.

Single Logout (SLO)

When a user logs out from one system, all SSO-enabled applications simultaneously log out. This prevents information leakage from forgotten logouts. Implementation: first log out the SSO application, then redirect each application to MaxKey's SLO page, which terminates the user's session. Since SSO and applications use different domains, the authentication protocol handles identity propagation across systems.

Session Timeout Design

To conserve server resources and enhance security, inactive client sessions are automatically terminated. All timeouts are centrally controlled at the MaxKey level: MaxKey's inactivity timeout is set slightly longer than integrated applications' timeouts. Example: for a 30-minute inactivity termination, set MaxKey timeout to 30 minutes and application timeouts to 40 minutes. If an application session expires while the user is active elsewhere, the application redirects to the login page; MaxKey re-authenticates via SSO and redirects back to the original URL or application homepage.

Brute-Force Protection

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is deployed on login pages — adding a distorted alphanumeric field that humans easily read but computers struggle to recognize, preventing automated password guessing.

Consecutive Login Failure Lockout

Accounts are locked for a defined period after repeated failures. Example: 6 consecutive failed attempts locks the account for 2 hours, mitigating brute-force attacks.

Static Password Policies

Enforced policies include: (1) complexity requirements, (2) minimum length, (3) maximum age, (4) minimum age, (5) password history enforcement, (6) reversible encryption storage (though the article notes this is less secure).

Multi-Factor Authentication (MFA)

MFA combines "something you know" (password) with "something you have" (dynamic token). Time-synchronized one-time passwords (OTP) replace static passwords. Each token has a unique key stored on both token and server; both compute OTP using the same key, time/event parameter, and algorithm. This creates layered defense, making unauthorized access significantly harder.

Password Storage: bcrypt Implementation

MaxKey uses Spring Security for password encryption/validation. The default strategy is BCrypt, stored in the userinfo table's password field as {type}ciphertext.

bcrypt Algorithm Details

bcrypt uses Bruce Schneier's 1993 Blowfish cipher. It randomly generates salt and embeds it in the final hash, eliminating separate salt handling during verification. Hash format:

$2a$10$/bTVvqqlH9UiE0ZJZ7N2Me3RIgUCdgMheyTgV0B4cMCSokPa.6oCa
$

— delimiter 2a — bcrypt version identifier 10 — cost factor (work factor)

First 22 characters after cost — salt value

Remaining characters — password ciphertext

bcrypt Characteristics

bcrypt is intentionally slow — thousands of times slower than MD5 — dramatically increasing rainbow-table attack cost. Each encryption produces a unique hash even for identical passwords, preventing cross-site credential leakage if one site's hashes are exposed. Developers must ensure the computational delay stays within system tolerance.

Why Not MD5

MD5 is a hash digest, not encryption. Rainbow tables have rendered MD5 and SHA-1 insecure for password storage. Public decryption sites (e.g., cmd5) easily reverse common MD5/SHA-1 hashes.

Repository Links

Gitee: https://gitee.com/dromara/MaxKey GitHub: https://github.com/dromara/MaxKey Official Site:

http://www.maxkey.top
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

open-sourcesecurityauthenticationSSOOAuthSAMLbcryptMaxKey
Architect's Guide
Written by

Architect's Guide

Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.