User Security Architecture: Handling Compromise, RBAC, and Token Revocation

Reading source: Yin Hongliang "Architecture Fundamentals: From Requirements to Architecture" Chapter 5.

Chapter Core Overview

The most challenging moments in user security often occur after an account has been compromised, permissions misconfigured, or credentials leaked. This chapter revolves around the full user account lifecycle: login kickout, password security, password recovery and modification, registration, RBAC permissions, and Token/JWT access control. Their common goal is to control three questions: who can establish identity, what can the identity do, and when does the identity expire.

User security is not merely a few validation rules on the login page; it is a system composed of identity data, credentials, sessions, permissions, risk events, and audit logs. The more critical the security control, the more it must be enforced uniformly by the server side, retaining evidence for revocation, recovery, and accountability.

Key Knowledge Breakdown

5.1-5.2 Account Status and Login Kickout

Kickout mechanisms serve session expiration, same-endpoint mutual exclusion, permission changes, and system maintenance. Active kickout pushes a notification to the client for immediate exit, providing better user experience; passive kickout revokes the session or token, causing the next request to fail, offering higher determinism. In practice they can be combined: send an active notification first, then rely on server-side session state as the final control.

Account, credential, and session should be three independent states. Freezing an account must invalidate all valid sessions; modifying high-risk permissions should require re-authentication; both logout and kickout must record reason, operator, and timestamp.

5.3 Password Security

Password policies cover complexity, weak password checks, password history, expiration, failure lockout, and secure transmission and storage. Complexity and periodic rotation increase user burden and should be risk-tiered, combined with multi-factor authentication and anomaly detection, avoiding uniform cost for all users.

The book uses MD5 with salt to illustrate irreversible storage thinking. In production, do not copy the specific algorithm; instead adopt an organization-approved dedicated password hashing scheme, using per-account independent random salts, reasonable cost parameters, and support for algorithm upgrades. Transmission relies on properly validated TLS; client-side "password encryption" cannot replace secure transport nor prevent replay attacks.

5.4-5.6 Recovery, Modification, and Registration

Password recovery is essentially re-proving identity to reset credentials, not retrieving the original password. Phone, email, security questions, manual review, and biometrics have different trust levels and should be combined based on account value. Reset links or codes must be short-lived, single-use, and bound to the target account and operation scenario; on success, revoke other sessions and notify the user.

Open, closed, and semi-closed registration reflect different governance models. The registration flow must define account source, activation method, review responsibility, and initial permissions. Internationalized products cannot assume all users use phone numbers as primary identity identifiers.

5.7 RBAC Permission Model

RBAC decouples users from permissions via roles, and can reduce configuration cost through role inheritance, user groups, and permission groups. The more complex the model, the more important it is to prevent implicit inheritance leading to over-privilege. Roles should map to real responsibilities; sensitive operations must follow least privilege, separation of duties, and periodic review.

Functional permissions only answer "can this operation be executed"; data permissions must also answer "which data can be operated on". Both should be expressed in the authorization model and verified by the server at the resource access point.

5.8 Token, Secret, and JWT

Centralized tokens facilitate active revocation and unified governance but require high availability for the auth service and session store. JWT allows resource services to verify signatures locally, reducing central query pressure, but tokens cannot be immediately revoked after issuance, and payloads are readable — sensitive information must not be placed in them.

SecretID/SecretKey suit system identities; they must be stored securely, rotated regularly, and scoped with limited permissions. Access tokens and refresh tokens should have different lifetimes and purposes; refresh must validate client, original session, and refresh credential, and rotation must invalidate the old refresh credential.

Architecture Diagram Explanation

The first diagram describes the runtime chain of authentication, session, and authorization; the second emphasizes that user, credential, session, and permission should be modeled separately.

Personal Learning Reflections

This chapter covers a lot, but the two actions I truly remember are revocation and recovery. Login, tokens, role configuration all discuss how to grant capabilities; real systems must also answer how to stop the bleeding after credential leakage, permission misconfiguration, and personnel departure. A security model that only grants permissions is incomplete.

This also changed how I view platform permissions. RBAC itself is not hard; the difficulty is whether the organization is willing to split responsibilities: can the person who modifies the pipeline approve their own production release, does viewing build logs imply access to sensitive variables, should tasks use personal credentials or service identities. The book provides the model; boundaries must still be determined in concrete work.

Implementation Checklist

Establish a unified data model for users, accounts, credentials, devices, sessions, and permissions.

Use dedicated hashing algorithms with independent random salts for passwords, and design a smooth upgrade mechanism.

Consider account, IP, device, and time window simultaneously for login failures, avoiding pure account lockout being used for denial of service.

Require re-authentication and send security notifications for sensitive operations such as recovery, rebinding, and privilege escalation.

Permission changes and account freezes must be able to quickly revoke related sessions.

Enforce separation of duties, approval, periodic review, and operation auditing for high-risk roles.

Establish custody, rotation, and leakage response processes for keys, secrets, and refresh credentials.

Key Validation

Design security test cases around account takeover, privilege escalation, stale sessions not revoked, weak passwords, replay attacks, and permission inheritance errors. Each test case must verify server-side results and audit records, not just frontend prompts.