Think of a GrantedAuthority as being a “permission” or a “right”. Those “permissions” are (normally) expressed as strings (with the getAuthority() method). Those strings let you identify the permissions and let your voters decide if they grant access to something.
You can grant different GrantedAuthoritys (permissions) to users by putting them into the security context. You normally do that by implementing your own UserDetailsService that returns a UserDetails implementation that returns the needed GrantedAuthorities.
Roles (as they are used in many examples) are just “permissions” with a naming convention that says that a role is a GrantedAuthority that starts with the prefix ROLE_. There’s nothing more. A role is just a GrantedAuthority - a “permission” - a “right”. You see a lot of places in spring security where the role with its ROLE_ prefix is handled specially as e.g. in the RoleVoter, where the ROLE_ prefix is used as a default. This allows you to provide the role names without the ROLE_ prefix. Prior to Spring security 4, this special handling of “roles” has not been followed very consistently and authorities and roles were often treated the same (as you e.g. can see in the implementation of the hasAuthority() method in SecurityExpressionRoot - which simply calls hasRole()). With Spring Security 4, the treatment of roles is more consistent and code that deals with “roles” (like the RoleVoter, the hasRole expression etc.) always adds the ROLE_ prefix for you. So hasAuthority(‘ROLE_ADMIN’) means the the same as hasRole(‘ADMIN’) because the ROLE_ prefix gets added automatically. See the spring security 3 to 4 migration guide for further information.
But still: a role is just an authority with a special ROLE_ prefix:
- in Spring security 3
@PreAuthorize(“hasRole(‘ROLE_XYZ’)”)is the same as@PreAuthorize(“hasAuthority(‘ROLE_XYZ’)”) - in Spring security 4
@PreAuthorize(“hasRole(‘XYZ’)”)is the same as@PreAuthorize(“hasAuthority(‘ROLE_XYZ’)”)