Identity & access

Centralized SSO is more than a login screen

Connecting identity, roles, and application boundaries, informed by my Spring Boot work at Prokoders.

The work behind the topic

At Prokoders, I led development of a centralized single sign-on platform using Java 21, Spring Boot, Spring Security, OAuth 2.0, SAML, and JWT-based authentication. The scope included role-based access, OTP, device trust, and audit-focused controls. That combination makes identity a platform concern: applications need a shared understanding of who the user is while retaining responsibility for the actions that user can perform.

Keep the responsibilities explicit

A useful design review separates sign-in, session handling, and resource authorization. A successful sign-in should not grant access to every business record. Each service still needs to check its own permissions and resource boundaries. Document which component issues credentials, which validates them, and how changes in a user’s access become effective. Otherwise, different applications can interpret the same identity differently.

Review the complete identity lifecycle

Testing should follow more than the first login. Include expired credentials, changed roles, disabled accounts, failed OTP attempts, and logout across connected applications. Define the expected result for each scenario before implementing the checks. Audit records should help reconstruct an access decision without recording secrets. These are review questions for an identity system, not claims that a particular protocol or token format solves every security requirement.

Back to all articles