How MaxKey SSO Delivers Secure, Scalable Single Sign‑On for Enterprises

Project Introduction

MaxKey SSO authentication system, named after "Max Key" (the greatest key), supports OAuth 2.x/OpenID Connect, SAML 2.0, JWT, CAS, SCIM and other standard protocols, providing simple, standard, secure and open user identity management (IDM), authentication (AM), single sign‑on (SSO), RBAC permission management and resource management.

Single Sign On (SSO) allows users to log in once and access all mutually trusted applications without re‑authentication. Main functions:

All application systems share a single authentication system.

All application systems can recognize and extract ticket information.

MaxKey emphasizes performance, security and ease of use in enterprise scenarios and is widely used in medical, financial, government and manufacturing industries.

Features

Standard Authentication Protocols

Login Support

Provides standard authentication interfaces for easy SSO integration, secure mobile access, secure API, third‑party and internet authentication.

Offers user lifecycle management, supporting SCIM 2.0; out‑of‑the‑box connectors implement identity provisioning synchronization.

Simplifies Microsoft Active Directory, standard LDAP server structures and account management, with self‑service password reset.

IDaaS multi‑tenant capability supports independent management of multiple enterprises under a group or departmental data isolation, reducing O&M costs.

The authentication center is platform‑agnostic and supports diverse environments, including web, smartphones and mobile devices such as iOS and Android, covering B/S to mobile applications.

Configurable password and access policies; supports Ip2region or GeoLite2 for precise IP location, strong security auditing, full‑lifecycle audit, access behavior tracing, compliance audit, risk warning.

Based on Java EE micro‑service architecture, using Spring, MySQL, Tomcat, Redis, MQ and other open‑source technologies, offering strong extensibility.

Open‑source, secure and self‑controlled.

Main Interface

Real‑time Reports

User Management

Application Management

System Security

Secondary Password Login

SSO lets users log in once, but for certain sensitive applications a second password verification can be required to prevent data leakage, such as financial systems or personal payroll statements, especially when account delegation occurs.

Single Logout

When a user logs out of one system, all SSO‑connected systems log out simultaneously, enhancing security by preventing forgotten sessions. Implementation involves using MaxKey’s single‑logout page to invalidate sessions across applications.

Session Timeout Design

To conserve server resources and improve security, idle client sessions are automatically terminated. MaxKey’s session timeout is set slightly longer than integrated applications to keep SSO functional. For example, a 30‑minute idle timeout on MaxKey and a 40‑minute timeout on the integrated app ensures seamless re‑authentication via SSO when needed.

Brute‑Force Protection

To prevent automated password guessing, MaxKey employs CAPTCHA, requiring users to enter a distorted code that is easy for humans but difficult for computers.

Consecutive Login Failure Policy

Accounts can be locked for a period after multiple consecutive failed logins (e.g., 6 failures → 2‑hour lock), mitigating brute‑force attacks.

Static Password Policy

Password policies enforce complexity, minimum/maximum length, usage periods, history, and encrypted storage.

Two‑Factor Authentication

Combines something you know with something you have. It uses time‑synchronised one‑time passwords generated from a secret key, providing multi‑layer defense and improving security.

Password Storage

Implemented with Spring Security; passwords are stored with a prefix indicating the encoding type. MaxKey’s default encryption strategy is BCrypt, and the password field stores data as {type}ciphertext.

BCrypt Encoding Algorithm

BCrypt is based on the Blowfish encryption algorithm. It mixes a random salt into the final hash, eliminating the need to manage the salt separately. A typical BCrypt hash looks like:

$2a$10$/bTVvqqlH9UiE0ZJZ7N2Me3RIgUCdgMheyTgV0B4cMCSokPa.6oCa

Explanation: $ is a delimiter; 2a indicates the BCrypt version; 10 is the cost factor; the next 22 characters constitute the salt; the remaining string is the ciphertext.

BCrypt Characteristics

BCrypt is intentionally slow, making rainbow‑table attacks impractical. Each hash is unique even for identical passwords, providing strong security.

MD5 Not Recommended

MD5 is a hash, not an encryption algorithm, and is vulnerable to rainbow‑table attacks; it should not be used for password storage.

Related Links

Gitee: https://gitee.com/dromara/MaxKey

GitHub: https://github.com/dromara/MaxKey

Official website: http://www.maxkey.top