Skip to main content

The Authorization Model: Authorities vs. Roles

Once a user is authenticated, Spring Security evaluates their privileges to determine whether they are authorized to access given endpoints or execute specific methods.

All privileges in Spring Security are represented through the GrantedAuthority interface. However, two distinct design approaches are supported:

GrantedAuthority: Authorities vs Roles

1. Authorities (Atomic Permissions / Actions)​

Represent fine-grained actions or granular operations on domain entities. They specify precisely what the user can execute:

  • Examples: READ, WRITE, DELETE_USER, EXPORT_REPORT.
  • Checked in path configurations or security annotations via hasAuthority(): 
    .requestMatchers(HttpMethod.DELETE, "/mvc/users/**").hasAuthority("DELETE_USER")

2. Roles (Organizational Profiles / Job Titles)​

Represent high-level user profiles that aggregate a set of authorities.

  • Examples: Administrator, Manager, Customer, SalesRep.
  • The ROLE_ Prefix Convention: In Spring Security, a role is technically a GrantedAuthority prefixed with ROLE_ (e.g., ROLE_ADMIN, ROLE_USER).
  • When checking a role with hasRole("ADMIN"), Spring Security automatically appends the ROLE_ prefix under the hood: 
    // Both expressions evaluate identically:
    .requestMatchers("/mvc/admin/**").hasRole("ADMIN")
    .requestMatchers("/mvc/admin/**").hasAuthority("ROLE_ADMIN")

3. Architectural Best Practices for Complex Systems​

Decoupling Roles and Permissions in Relational Databases

In mature enterprise architectures, users are assigned to Roles, and each Role is mapped to a list of Permissions (Authorities) in the relational database.

This enables permission sets to be reconfigured dynamically at runtime in the database tables (roles, permissions, role_permissions) without requiring Java source code recompilation or application redeployment.

Self-Assessment Quiz​

Cargando cuestionario...