Authentication vs Authorization

What is Authentication vs Authorization — and Why Does the Distinction Matter?

Authentication (AuthN) answers "who is this?" — it verifies an identity against a set of credentials. Authorization (AuthZ) answers "what is this identity allowed to do?" — it checks a permission against a resource, and only runs after authentication has already established who is asking. They are two separate concerns solved by two separate mechanisms, and the moment an application tangles them together in the same block of code, one of two things happens: either authorization checks get skipped for some code paths, or a hand-rolled comparison replaces a hardened framework mechanism that already handles timing attacks, password hashing, and session fixation correctly.

The two failure modes have different HTTP status codes for exactly this reason: 401 Unauthorized means the identity could not be established (authentication failed), and 403 Forbidden means the identity is known but lacks permission for this specific action (authorization failed). Returning the wrong one is not cosmetic — it changes what a client, a monitoring dashboard, or an attacker can infer about your system.

// BEFORE — identity check and permission check tangled together in application code
protected void doPost(HttpServletRequest req, HttpServletResponse resp) {
    String username = req.getParameter("username");
    String password = req.getParameter("password");

    User user = userDao.findByUsername(username);
    if (user == null || !user.getPassword().equals(password)) {
        resp.setStatus(401);   // hand-rolled, plaintext comparison, no timing-attack protection
        return;
    }
    if (!user.getRole().equals("ADMIN")) {
        resp.setStatus(403);   // bolted onto the same method as identity verification
        return;
    }
    // ... business logic now buried under two unrelated security concerns
}

// AFTER — authentication is a filter-chain concern; authorization is declarative
@PreAuthorize("hasRole('ADMIN')")
@DeleteMapping("/api/admin/users/{id}")
public void deleteUser(@PathVariable Long id) {
    userService.delete(id);
    // By the time this line runs, Spring Security's filter chain has already
    // verified identity, and @PreAuthorize has already verified permission.
    // Neither concern is application code's responsibility here.
}

The Request Lifecycle

Authentication Methods — The Three Factors

Every authentication mechanism ultimately reduces to one of three factors: something you know, something you have, or something you are. Multi-factor authentication (MFA) means combining at least two different factor types — a password plus a TOTP code is two-factor; a password plus a security question is not, because both are knowledge-based and both are stolen the same way (phishing).

1. Knowledge-Based (Something You Know) — Password Authentication

// DTOs as records — no setters, no mutable state to leak a password reference around
public record LoginRequest(String username, String password) {}
public record AuthResponse(String token) {}

@RestController
@RequestMapping("/api/auth")
public class AuthController {

    private final AuthenticationManager authManager;
    private final JwtService jwtService;

    // Constructor injection — single constructor, no @Autowired needed (Spring 4.3+)
    public AuthController(AuthenticationManager authManager, JwtService jwtService) {
        this.authManager = authManager;
        this.jwtService = jwtService;
    }

    @PostMapping("/login")
    public ResponseEntity<AuthResponse> login(@RequestBody LoginRequest request) {
        Authentication auth = authManager.authenticate(
            new UsernamePasswordAuthenticationToken(request.username(), request.password())
        );
        // AuthenticationManager delegates to the PasswordEncoder — never compare
        // raw strings yourself, and never log the password, even on failure.
        String token = jwtService.generateToken(auth);
        return ResponseEntity.ok(new AuthResponse(token));
    }
}

// Custom UserDetailsService — the bridge between your User entity and Spring Security
@Service
public class CustomUserDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

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

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

        return new org.springframework.security.core.userdetails.User(
            user.getUsername(),
            user.getPassword(),        // already hashed — never store or compare raw
            user.isEnabled(),
            true, true, true,      // accountNonExpired, credentialsNonExpired, accountNonLocked
            toAuthorities(user.getRoles())
        );
    }
}

2. Possession-Based (Something You Have) — TOTP Second Factor

@Service
public class TwoFactorAuthService {

    private final GoogleAuthenticator gAuth = new GoogleAuthenticator();

    // Generate a per-user secret, shown to the user as a QR code once
    public String generateSecret() {
        return gAuth.createCredentials().getKey();   // store encrypted, never in plaintext logs
    }

    // Verify the 6-digit code from the user's authenticator app
    public boolean verifyCode(String secret, int code) {
        return gAuth.authorize(secret, code);
    }
}

// The login flow branches once the password step succeeds
@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody LoginRequest request) {
    Authentication auth = authManager.authenticate(
        new UsernamePasswordAuthenticationToken(request.username(), request.password())
    );

    User user = userService.findByUsername(request.username());

    if (user.isTwoFactorEnabled()) {
        if (request.totpCode() == null) {
            return ResponseEntity.ok(new TwoFactorRequiredResponse());
        }
        if (!twoFactorService.verifyCode(user.getTotpSecret(), request.totpCode())) {
            throw new BadCredentialsException("Invalid 2FA code");
        }
    }

    return ResponseEntity.ok(new AuthResponse(jwtService.generateToken(auth)));
}

3. Inherence-Based (Something You Are) — WebAuthn / Biometrics

// Biometrics never leave the device. The server verifies a cryptographic
// signature produced locally by the authenticator (fingerprint sensor, Face ID),
// it never receives a fingerprint image or template.
@PostMapping("/biometric-auth")
public ResponseEntity<AuthResponse> biometricAuth(@RequestBody BiometricAuthRequest request) {
    boolean valid = webAuthnService.verifyAssertion(
        request.userId(), request.authenticatorData(),
        request.signature(), request.clientDataJson()
    );

    if (!valid) {
        throw new BadCredentialsException("Biometric verification failed");
    }

    User user = userService.findById(request.userId());
    return ResponseEntity.ok(new AuthResponse(jwtService.generateToken(user)));
}

Authorization Models — RBAC, Permission-Based, and ABAC

Authorization models differ in what they check a permission against. RBAC checks a role. Permission-based checks a granular authority. ABAC checks an arbitrary combination of attributes about the subject, the resource, and the environment. Each is a legitimate default for a different level of complexity — reaching for ABAC when RBAC would have sufficed adds maintenance cost with no corresponding benefit.

1. Role-Based Access Control (RBAC)

// Simple RBAC: users have roles, roles have permissions
@Entity
public class User {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    @ManyToMany(fetch = FetchType.LAZY)   // LAZY by default — see the note below before reaching for EAGER
    @JoinTable(
        name = "user_roles",
        joinColumns = @JoinColumn(name = "user_id"),
        inverseJoinColumns = @JoinColumn(name = "role_id")
    )
    private Set<Role> roles = new HashSet<>();
}

@Entity
public class Role {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;   // ROLE_ADMIN, ROLE_MANAGER, ROLE_USER

    @ManyToMany(fetch = FetchType.LAZY)
    @JoinTable(
        name = "role_permissions",
        joinColumns = @JoinColumn(name = "role_id"),
        inverseJoinColumns = @JoinColumn(name = "permission_id")
    )
    private Set<Permission> permissions = new HashSet<>();
}

// Declarative role checks — Spring AOP evaluates these before the method body runs
@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @PreAuthorize("hasRole('ADMIN')")
    @GetMapping
    public List<User> getAllUsers() {
        return userService.findAll();
    }

    @PreAuthorize("hasAnyRole('ADMIN', 'MANAGER')")
    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return userService.findById(id);
    }
}

2. Permission-Based Access Control

// Fine-grained authorities instead of coarse roles
@RestController
@RequestMapping("/api/invoices")
public class InvoiceController {

    private final InvoiceService invoiceService;

    public InvoiceController(InvoiceService invoiceService) {
        this.invoiceService = invoiceService;
    }

    @PreAuthorize("hasAuthority('INVOICE_READ')")
    @GetMapping
    public List<Invoice> getInvoices() {
        return invoiceService.findAll();
    }

    // Combine a coarse authority check with an ownership check via SpEL
    @PreAuthorize("hasAuthority('INVOICE_DELETE') and #invoice.owner == authentication.name")
    @DeleteMapping("/{id}")
    public void deleteInvoice(@PathVariable Long id, Invoice invoice) {
        invoiceService.delete(id);
    }
}

// Custom permission evaluator for logic too complex for a single SpEL expression
@Component
public class InvoicePermissionEvaluator implements PermissionEvaluator {

    @Override
    public boolean hasPermission(Authentication auth, Object target, Object permission) {
        if (!(target instanceof Invoice invoice)) return false;

        String username = auth.getName();
        return switch ((String) permission) {
            case "READ"   -> invoice.getOwner().equals(username)
                              || invoice.getSharedWith().contains(username);
            case "WRITE", "DELETE" -> invoice.getOwner().equals(username);
            default -> false;
        };
    }

    @Override
    public boolean hasPermission(Authentication auth, Serializable targetId,
                                 String targetType, Object permission) {
        return false;   // load-by-id variant, implement only if you need it
    }
}

3. Attribute-Based Access Control (ABAC)

// ABAC evaluates a policy against subject, resource, action, and environment attributes
// simultaneously — used when role and permission alone can't express the rule.
@Service
public class InvoiceAccessPolicy {

    private final Set<String> trustedIps;

    public InvoiceAccessPolicy(@Value("${security.trusted-ips}") Set<String> trustedIps) {
        this.trustedIps = trustedIps;
    }

    // Policy: finance staff can read invoices from their own department;
    // writing also requires business hours and a trusted network location.
    public boolean canAccess(User user, Invoice invoice, String action, AccessContext context) {
        boolean sameDepartment = user.getDepartment().equals(invoice.getDepartment());
        boolean hasClearance   = user.getClearanceLevel() >= invoice.getClassificationLevel();
        boolean businessHours  = isWithinBusinessHours(context.time());
        boolean trustedNetwork = trustedIps.contains(context.ipAddress());

        return switch (action) {
            case "READ"  -> sameDepartment && hasClearance;
            case "WRITE" -> sameDepartment && hasClearance && businessHours && trustedNetwork;
            case "DELETE" -> invoice.getOwner().equals(user.getId()) && user.getClearanceLevel() >= 4;
            default -> false;
        };
    }
}

Wiring It Together — Spring Security Configuration

The filter chain is where authentication happens (the JWT filter, or the username/password filter). authorizeHttpRequests and @PreAuthorize are where authorization happens. Keeping them visually separate in the configuration mirrors the conceptual separation — resist the temptation to smuggle authorization logic into a custom authentication filter.

@Configuration
@EnableWebSecurity
@EnableMethodSecurity   // enables @PreAuthorize / @PostAuthorize / @PostFilter
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtFilter;
    private final ObjectMapper objectMapper;

    // Constructor injection — single constructor, no @Autowired needed (Spring 4.3+)
    public SecurityConfig(JwtAuthenticationFilter jwtFilter, ObjectMapper objectMapper) {
        this.jwtFilter = jwtFilter;
        this.objectMapper = objectMapper;
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable())   // safe for a stateless, token-based API — see CSRF notes on the CORS page
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS))

            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/auth/**", "/api/public/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .requestMatchers("/api/manager/**").hasAnyRole("ADMIN", "MANAGER")
                .requestMatchers(HttpMethod.DELETE, "/api/**").hasAuthority("DELETE_PRIVILEGE")
                .anyRequest().authenticated()
            )

            .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class)

            // ProblemDetail (RFC 9457) instead of a hand-rolled body — consistent with every
            // other error response in the application, see the REST error-handling topic.
            .exceptionHandling(ex -> ex
                .authenticationEntryPoint((req, res, e) -> {
                    ProblemDetail problem = ProblemDetail.forStatusAndDetail(
                        HttpStatus.UNAUTHORIZED, "Authentication is required to access this resource");
                    res.setContentType(MediaType.APPLICATION_PROBLEM_JSON_VALUE);
                    res.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
                    objectMapper.writeValue(res.getWriter(), problem);
                })
                .accessDeniedHandler((req, res, e) -> {
                    ProblemDetail problem = ProblemDetail.forStatusAndDetail(
                        HttpStatus.FORBIDDEN, "You do not have permission to perform this action");
                    res.setContentType(MediaType.APPLICATION_PROBLEM_JSON_VALUE);
                    res.setStatus(HttpServletResponse.SC_FORBIDDEN);
                    objectMapper.writeValue(res.getWriter(), problem);
                })
            )
            .build();
    }

    @Bean
    public AuthenticationManager authenticationManager(AuthenticationConfiguration config) throws Exception {
        return config.getAuthenticationManager();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();   // see Password Hashing for why bcrypt and not MD5/SHA-256
    }
}

Common Patterns — Role Hierarchy and Resource Ownership

Role Hierarchy

@Bean
public RoleHierarchy roleHierarchy() {
    return RoleHierarchyImpl.withDefaultRolePrefix()
        .role("ADMIN").implies("MANAGER")
        .role("MANAGER").implies("USER")
        .build();
}
// ADMIN now automatically satisfies hasRole('MANAGER') and hasRole('USER') checks
// without every @PreAuthorize expression having to spell out hasAnyRole(...)

Resource Ownership — Verify at the Layer Where the Data Lives

// Option A: express ownership directly in the @PreAuthorize expression
@GetMapping("/api/users/{userId}/orders")
@PreAuthorize("#userId == authentication.principal.id or hasRole('ADMIN')")
public List<Order> getUserOrders(@PathVariable Long userId) {
    return orderService.findByUserId(userId);
}

// Option B: verify ownership in the service layer — necessary when the check
// depends on data that must be loaded first, or when the service is also called
// from non-HTTP entry points (batch jobs, message listeners) that never go through
// a controller and therefore never go through @PreAuthorize.
@Service
public class OrderService {

    private final OrderRepository orderRepository;

    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public Order getOrder(Long orderId) {
        Order order = orderRepository.findById(orderId)
            .orElseThrow(() -> new OrderNotFoundException(orderId));

        String currentUser = SecurityContextHolder.getContext().getAuthentication().getName();
        if (!order.getOwner().equals(currentUser)) {
            throw new AccessDeniedException("Not your order");
        }
        return order;
    }
}

Best Practices and Common Pitfalls

Interview Questions