Granted Authority Versus Role in Spring Security

Last updated: January 8, 2024

Written by: baeldung

Reviewed by: Kevin Gilmore

Spring Security

Authorization

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

1. Overview

In this quick article, we’ll explain the subtle but significant difference between a Role and a GrantedAuthority in Spring Security. For more detailed information on roles and authorities, see the article here.

Spring Security Basic Authentication

Set up Basic Authentication in Spring - the XML Configuration, the Error Messages, and example of consuming the secured URLs with curl.

2. GrantedAuthority

In Spring Security, we can think of each GrantedAuthority as an individual privilege. Examples could include READ_AUTHORITY, WRITE_PRIVILEGE, or even CAN_EXECUTE_AS_ROOT. The important thing to understand is that the name is arbitrary.

When using a GrantedAuthority directly, such as through the use of an expression like hasAuthority(‘READ_AUTHORITY’), we are restricting access in a fine-grained manner.

As you can probably gather, we can refer to the concept of authority by using privilege as well.

3. Role as Authority

Similarly, in Spring Security, we can think of each Role as a coarse-grained GrantedAuthority that is represented as a String and prefixed with “ROLE“. When using a Role directly, such as through an expression like hasRole(“ADMIN”), we are restricting access in a coarse-grained manner.

It is worth noting that the default “ROLE” prefix is configurable, but explaining how to do that is beyond the scope of this article.

The core difference between these two is the semantics we attach to how we use the feature. For the framework, the difference is minimal – and it basically deals with these in exactly the same way.

4. Role as Container

Now that we’ve seen how the framework uses the role concept, let’s also quickly discuss an alternative – and that is using roles as containers of authorities/privileges.

This is a higher level approach to roles – making them a more business-facing concept rather than an implementation-centric one.

The Spring Security framework doesn’t give any guidance in terms of how we should use the concept, so the choice is entirely implementation specific.

5. Spring Security Configuration

We can demonstrate a fine-grained authorization requirement by restricting access to /protectedbyauthority to users with READ_AUTHORITY.

We can demonstrate a coarse-grained authorization requirement by restricting access to /protectedbyrole to users with ROLE_USER.

Let’s configure such a scenario in our security configuration:

@Override
protected void configure(HttpSecurity http) throws Exception {
    // ...
    .requestMatchers("/protectedbyrole").hasRole("USER")
    .requestMatchers("/protectedbyauthority").hasAuthority("READ_PRIVILEGE")
    // ...
}

6. Simple Data Init

Now that we understand the core concepts better, let’s talk about creating some setup data when the application starts up.

This is, of course, a very simple way of doing that, to hit the ground running with some preliminary test users during development – not the way you should handle data in production.

We’re going to be listening for the context refresh event:

@Override
@Transactional
public void onApplicationEvent(ContextRefreshedEvent event) {
    MyPrivilege readPrivilege
      = createPrivilegeIfNotFound("READ_PRIVILEGE");
    MyPrivilege writePrivilege
      = createPrivilegeIfNotFound("WRITE_PRIVILEGE"); 
}

The actual implementation here doesn’t really matter – and generally, depends on the persistence solution you’re using. The main point is – we’re persisting the authorities we’re using in the code.

7. UserDetailsService

Our implementation of UserDetailsService is where the authority mapping takes place. Once the user has authenticated, our getAuthorities() method populates and returns a UserDetails object:

private Collection<? extends GrantedAuthority> getAuthorities(
  Collection<Role> roles) {
    List<GrantedAuthority> authorities = new ArrayList<>();
    for (Role role: roles) {
        authorities.add(new SimpleGrantedAuthority(role.getName()));
        authorities.addAll(role.getPrivileges()
                 .stream()
                 .map(p -> new SimpleGrantedAuthority(p.getName()))
                 .collect(Collectors.toList()));
    }
    
    return authorities;
}