Spring Security — Basic Auth

1 · Notebook summaryCopy this by hand#

Dense, telegraphic, liftable. Everything here is derived from the detailed notes below.

2 · Detailed study referenceThe lesson, in full#

In 2018, anyone who knew the shape of one web address could read the personal records of millions of Panera Bread customers: names, email and home addresses, birthdays, the last four digits of their cards. The data sat behind an API endpoint that simply never asked the visitor to prove anything. It leaked, in the open, for at least eight months. Nobody had to break in, because there was no lock on the door. That is the whole subject of this lesson: the lock, where it hangs, and who is allowed through it.

2.1Why an API needs a guard at all#

An API endpoint is a door into your data, and by default it is unlocked. A web API takes requests over the network and hands back data or performs actions. If nothing checks the visitor, then anyone who can name the address gets whatever is behind it. The Panera leak was not a clever hack; it was the absence of a check.

The consequences of skipping the check are not abstract. Leaked personal data feeds identity theft and fraud; exposed financial data enables direct theft; leaked contact lists power targeted phishing; and beyond the victims, the company itself absorbs reputational damage, legal fines for breaking data-protection rules, and the operational cost of cleaning up instead of building. The takeaway the slides press hard: securing endpoints is not optional polish, it is a baseline requirement for any real application.

The attacks a guard defends against#

Five common attack shapes come up. You do not implement defenses against all of them today, but you should recognize each and name its standard prevention.

2.2Authentication vs authorization#

Authentication proves who you are; authorization decides what you're allowed to do. They sound similar and are constantly confused, but they answer different questions and happen in a fixed order — you cannot decide someone's privileges until you know who they are.

Start from the everyday version. You can Google-search without logging in, but you cannot like a YouTube video or edit a LinkedIn post without one. Some actions need to know who is acting; others don't. And once the system knows you, a second gate opens: on an e-commerce site, Ram may add products to his own cart, but not to Shyam's. Knowing his identity (authentication) is not the same as being permitted the action (authorization).

2.3What Spring Security is#

Spring Security is a framework that stands guard in front of your Spring Boot app, checking every request before your own code sees it. It watches who accesses the site, verifies identities, and enforces access rules — the exact set of problems the section above laid out.

To see where it plugs in, you need one fact about how Spring Boot handles web traffic. Spring Boot uses Spring MVC underneath, and in Spring MVC every incoming HTTP request funnels through a single dispatch box (the DispatcherServlet) that then routes it to the right controller method. Spring Security inserts a stack of filter classes before that dispatch box. So a request is inspected and, if needed, rejected, before it is ever handed to your controller.

2.4The pieces inside the guard#

Spring Security is not one object; it is a small cast of collaborators, each with one job. Learn the cast and the architecture diagram stops being intimidating. You configure these once, at the start of a project — the goal is a high-level grasp of how they hand off to each other, not memorizing every setter.

2.5How one request flows through it#

Put the cast in motion. When a request arrives, this is the sequence, and it is a favorite thing to be asked to narrate.

1. The Security Filter Chain intercepts the request first.
2. If the user isn't authenticated yet, the auth filters trigger the Authentication Manager.
3. The Manager hands the credentials to a configured Authentication Provider.
4. The Provider uses the UserDetailsService to load the user from the database, and the PasswordEncoder to compare the submitted password against the stored hash.
5. The result is returned to the user as success or a 401 Unauthorized.
6. On success, the Authentication object is stored in the SecurityContextHolder — the context now represents the logged-in user for the rest of the request.

2.6Setting up basic authentication#

Basic authentication is the simplest scheme: the client sends its username and password with every request, and the server checks them each time. Spring Security gives you this almost for free. On start.spring.io↗ you generate a project with two dependencies — Spring Web and Spring Security — and the moment the security dependency is on the classpath, something surprising happens.

Write a trivial endpoint, run the app with ./gradlew bootRun, and visit it — you're bounced to a login page. Enter user and the terminal password, and the resource loads.

@RestController
@RequestMapping("/api/v1")
public class TestController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello from authenticated endpoint!";
    }
}

To move past the generated user and take control of the rules, you define your own Security Filter Chain bean. This one permits sign-up freely, requires a login everywhere else, and turns on HTTP Basic:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf(csrf -> csrf.disable()).authorizeHttpRequests(auth -> auth.requestMatchers("/signup/**").permitAll()   // open
        .requestMatchers("/users/**").authenticated() // login required
        .anyRequest().authenticated()).httpBasic(Customizer.withDefaults());            // Basic Auth
        return http.build();
    }
}

The provider needs to know where users come from and how their passwords are hashed. That is the job of a UserDetailsService plus a PasswordEncoder, wired into a DaoAuthenticationProvider:

@Service
public class UserDetailsServiceImpl implements UserDetailsService {

    private final UserRepository userRepository;

    public UserDetailsServiceImpl(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public UserDetails loadUserByUsername(String email) {
        User user = userRepository.findByEmail(email).orElseThrow(() -> new UsernameNotFoundException("Not found: " + email));

        return org.springframework.security.core.userdetails.User.withUsername(user.getEmail()).password(user.getPassword())     // already BCrypt-hashed in DB
        .roles(user.getRole().name())     // e.g. "USER" or "ADMIN"
        .build();
    }
}

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();   // salts each password
}

@Bean
public AuthenticationProvider authenticationProvider(UserDetailsService uds) {
    DaoAuthenticationProvider provider = new DaoAuthenticationProvider();
    provider.setUserDetailsService(uds);
    provider.setPasswordEncoder(passwordEncoder());
    return provider;
}

Anywhere inside a request you can ask who the current user is by reading the Principal out of the SecurityContextHolder:

Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
String username = authentication.getName();

What "Basic Auth" looks like on the wire#

Basic Auth is not magic: the client encodes username:password in base64 and puts it in an Authorization header on every request. The server decodes it, runs the flow above, and answers.

2.7Role-based access control#

Role-based access control (RBAC) gives each user a role, and each role a fixed set of permissions — so access is decided by role, not by hand for every person. This is authorization made manageable. Instead of "can Abdul see reports? can Priya?", you say "Admins see reports," and assign Abdul the Admin role.

RBAC matters for APIs on four counts: security (users reach only what they need), simpler management (assign a role, not a pile of individual permissions), consistency (everyone in a role gets the same access — no more, no less), and compliance (regulators want provable control over who touches sensitive data).

2.8Testing it with Postman#

With the app running (./gradlew bootRun), you register two users through the API — one plain USER and one ADMIN — by POSTing JSON to the register endpoint:

{
  "name": "Abdul Rahman",
  "email": "abdulr@criodo.com",
  "password": "strongpassword",
  "role": "ADMIN"
}

Then, in Postman's Authorization tab, choose type Basic Auth and fill in a registered user's email and password. Postman attaches the Authorization header to every request you send. Now probe the endpoints and watch the status codes tell the authN/authZ story:

2.9Interview & practice Q&A#

2.10Key takeaways#

• An unsecured endpoint is an open door — the Panera leak was missing checks, not a sophisticated attack.
• Authentication (who are you? → 401 on fail) always precedes authorization (what may you do? → 403 on fail).
• Spring Security runs as a filter chain in front of the DispatcherServlet, so it guards requests before controllers.
• The cast: Filter Chain → Authentication Manager → Authentication Provider → UserDetailsService + PasswordEncoder → SecurityContextHolder.
• Adding the dependency secures everything by default; you opt out with permitAll().
• Hash passwords with BCrypt (salted); NoOp stores plaintext and must never ship.
• Basic Auth = base64 credentials on every request — safe only over HTTPS.
• RBAC gates endpoints by role; mind the ROLE_ prefix when using hasRole.

3 · MicroexercisesNow do it yourself#

Reading proves you recognize the pattern. These prove you can produce it. Attempt each before opening the walkthrough — both are runnable in your head or a scratch file.

3.1Build it — a Security Filter Chain#

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf(csrf -> csrf.disable()).authorizeHttpRequests(auth -> auth.requestMatchers("/signup/**").permitAll().requestMatchers("/users/**").authenticated().anyRequest().authenticated()).httpBasic(Customizer.withDefaults());
        return http.build();
    }
}

3.2Diagnose it — the admin who can't get in#

.authorizeHttpRequests(auth -> auth
    .requestMatchers("/admins").hasRole("ROLE_ADMIN")
    .anyRequest().authenticated())

.authorizeHttpRequests(auth -> auth
    .requestMatchers("/admins").hasRole("ADMIN")          // adds ROLE_ for you
    // .requestMatchers("/admins").hasAuthority("ROLE_ADMIN")  // equivalent
    .anyRequest().authenticated())