Implementing Authentication and Authorization in Enterprise Applications

Course: Advanced Java Training

Topic: Implementing Authentication and Authorization in Enterprise Applications

Course Link: Advanced Java Training Course

Demo Link: Register for a Course Demo

JustAcademy Homepage: Visit JustAcademy

1. Introduction

Authentication and authorization are fundamental security mechanisms in enterprise applications. They help protect sensitive data, restrict access to business operations, and ensure that users can perform only the actions permitted by the application.

In an Advanced Java application, these mechanisms may be implemented using Jakarta Servlet security, Spring Security, session management, token-based authentication, database-backed user accounts, and role-based access control. The appropriate approach depends on the application's architecture, deployment environment, and security requirements.

For example, in an employee management application, an employee may view their own profile, an HR executive may update employee records, and an administrator may manage user accounts and permissions.

Learning Objectives

• Understand authentication and authorization.
• Learn how identity, roles, permissions, and access policies work together.
• Implement secure login and logout flows in Java applications.
• Understand session-based and token-based authentication.
• Protect web pages, APIs, and business services.
• Apply password hashing, input validation, and secure session practices.
• Recognize common security vulnerabilities and testing techniques.

2. Authentication vs. Authorization

Authentication should generally occur before protected actions are authorized. However, authorization must also verify resource-specific conditions, such as whether the current user owns the requested record.

3. Core Security Concepts

3.1 Identity

An identity represents a user, service, application, or other principal interacting with a system. It may include a unique user ID, username, email address, and associated attributes.

3.2 Credentials

Credentials are used to prove an identity. Examples include passwords, passkeys, one-time codes, certificates, and tokens issued by a trusted identity provider. Credentials must be protected from disclosure and misuse.

3.3 Roles

A role groups users according to their responsibilities. Common roles include ADMIN, HR, MANAGER, and EMPLOYEE.

3.4 Permissions

A permission represents an allowed action on a resource, such as EMPLOYEE_READ, EMPLOYEE_UPDATE, or USER_MANAGE.

3.5 Principal and Security Context

A principal represents the authenticated identity associated with a request. A security context stores information about that identity and its granted authorities so that application components can make access-control decisions.

4. Common Access-Control Models

RBAC is a practical starting point for many business applications. Real enterprise systems often combine roles with permissions, resource ownership, department boundaries, and other policy checks.

5. Authentication Architecture in a Java Enterprise Application

A typical application uses a login interface, an authentication service, a user repository, a password-verification mechanism, and a security framework or filter. After authentication, a session or token carries the identity into subsequent requests.

Browser or API Client
        |
        v
HTTPS Request
        |
        v
Security Filter / Authentication Entry Point
        |
        v
Authentication Service
        |
        v
User Repository + Password Hash Verification
        |
        v
Authenticated Principal
        |
        v
Authorization Rules
        |
        v
Controller / Servlet / Service
        |
        v
Business Operation and Database

Typical login flow

1. The user submits credentials over HTTPS.
2. The application validates the request format and applies rate limits.
3. The authentication service loads the user's account by a stable identifier.
4. The submitted password is verified against the stored password hash.
5. The application checks whether the account is active and whether additional authentication is required.
6. On success, the framework creates a secure session or issues an appropriately protected token.
7. For each protected request, authorization rules determine whether the identity can perform the requested operation.
8. The application records appropriate security events without logging passwords, tokens, or other secrets.

6. Setting Up Spring Security

Spring Security is widely used in Spring-based Java applications to handle authentication, authorization, security filters, session policies, and common web security protections. The examples below use the modern bean-based configuration style. Use dependency versions compatible with the Spring Boot version selected for your project.

6.1 Maven dependencies

For a Spring Boot application, include the web and security starters. Let the Spring Boot parent or dependency-management configuration manage compatible versions.

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
</dependencies>

If user accounts are stored in a relational database, add the appropriate persistence and database-driver dependencies as required by the application. For production systems, select supported versions and keep them updated.

6.2 Define a password encoder

Never store plaintext passwords or use a fast general-purpose hash such as plain SHA-256 for password storage. Use a password-hashing algorithm designed to resist guessing attacks, such as Argon2id or bcrypt, with an appropriate configuration and unique salt handled by the library.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;

@Configuration
public class PasswordConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

This example uses bcrypt for illustration. For a new deployment, evaluate current guidance for password hashing, including work factor, memory requirements where applicable, and operational performance. Do not change the encoder configuration without planning how existing password hashes will be verified or upgraded.

6.3 Configure authentication and URL authorization

The following example illustrates URL-based access rules. It uses in-memory accounts only for demonstration and testing; production applications should normally use a properly managed identity store or an established identity provider.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
public class SecurityConfig {

    @Bean
    public UserDetailsService userDetailsService(
            PasswordEncoder passwordEncoder) {

        UserDetails admin = User.withUsername("admin")
            .password(passwordEncoder.encode("ChangeThisForDemoOnly"))
            .roles("ADMIN")
            .build();

        UserDetails employee = User.withUsername("employee")
            .password(passwordEncoder.encode("ChangeThisForDemoOnly"))
            .roles("EMPLOYEE")
            .build();

        return new InMemoryUserDetailsManager(admin, employee);
    }

    @Bean
    public SecurityFilterChain securityFilterChain(
            HttpSecurity http) throws Exception {

        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/login", "/css/**", "/js/**").permitAll()
                .requestMatchers("/admin/**").hasRole("ADMIN")
                .requestMatchers("/employee/**")
                    .hasAnyRole("EMPLOYEE", "ADMIN")
                .anyRequest().authenticated()
            )
            .formLogin(Customizer.withDefaults())
            .logout(Customizer.withDefaults());

        return http.build();
    }
}

Important: The example contains a demonstration password and in-memory accounts. Do not reuse these credentials or deploy them as production accounts. Replace the sample user store with a persistent, securely managed identity source and use an appropriate account-provisioning process.

Understanding the configuration

• SecurityFilterChain defines the security rules applied to incoming HTTP requests.
• permitAll() allows access to specified public resources without signing in.
• hasRole("ADMIN") requires the ROLE_ADMIN authority by default.
• hasAnyRole(...) permits any one of the specified roles.
• authenticated() requires a successfully authenticated identity.
• formLogin() enables a form-based login flow.
• logout() configures the framework's logout support.

7. Database-Backed User Authentication

Enterprise applications commonly store account records in a database or delegate authentication to a trusted identity provider. A simplified relational design may include user accounts, roles, permissions, and join tables.

7.1 Example database schema

CREATE TABLE app_user (
    id BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    username VARCHAR(100) NOT NULL UNIQUE,
    password_hash VARCHAR(255) NOT NULL,
    enabled BOOLEAN NOT NULL DEFAULT TRUE,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE app_role (
    id BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    role_name VARCHAR(50) NOT NULL UNIQUE
);

CREATE TABLE user_role (
    user_id BIGINT NOT NULL,
    role_id BIGINT NOT NULL,
    PRIMARY KEY (user_id, role_id),
    FOREIGN KEY (user_id) REFERENCES app_user(id),
    FOREIGN KEY (role_id) REFERENCES app_role(id)
);

Identity-column syntax varies across database products. Adjust the DDL for the selected database, such as PostgreSQL, MySQL, or SQL Server.

7.2 Account-management requirements

• Use a unique, normalized account identifier and enforce uniqueness in the database.
• Store only password hashes produced by a suitable password encoder.
• Use parameterized SQL or a trusted ORM to prevent SQL injection.
• Represent disabled, locked, expired, or unverified accounts explicitly when needed.
• Apply least privilege to database accounts and restrict access to credential tables.
• Plan password resets, account recovery, password-hash upgrades, and account deactivation.
• Use database transactions for related account and role changes.

8. Implementing Authorization at Multiple Layers

URL security is useful, but it is not sufficient on its own. Authorization should also be enforced in service methods and at resource boundaries. This prevents an alternate endpoint or an internal method call from bypassing the intended policy.

8.1 Method-level authorization

In Spring Security, enable method security and apply annotations to sensitive service operations.

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.method.configuration.EnableMethodSecurity;

@Configuration
@EnableMethodSecurity
public class MethodSecurityConfig {
}

import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.stereotype.Service;

@Service
public class EmployeeService {

    @PreAuthorize("hasRole('HR') or hasRole('ADMIN')")
    public void updateEmployee(Long employeeId) {
        // Validate input, apply business rules,
        // and update the employee record.
    }

    @PreAuthorize("hasRole('ADMIN')")
    public void deactivateAccount(Long userId) {
        // Apply account-deactivation workflow.
    }
}

The annotations express role requirements, but the implementation must still validate the requested record and business rules. Avoid relying on a user-supplied role or user ID without verifying it against the authenticated identity and authoritative data.

8.2 Resource ownership checks

Suppose an employee requests /employees/42. Being logged in does not automatically grant permission to view employee 42. The application should verify that the user is authorized for that specific record.

public Employee getEmployeeForCurrentUser(
        Long employeeId, CurrentUser currentUser) {

    Employee employee = employeeRepository.findById(employeeId)
        .orElseThrow(() -> new EmployeeNotFoundException(employeeId));

    boolean isAdmin = currentUser.hasRole("ADMIN");
    boolean isOwner = employee.getUserId()
        .equals(currentUser.userId());

    if (!isAdmin && !isOwner) {
        throw new AccessDeniedException("Access denied");
    }

    return employee;
}

CurrentUser, EmployeeNotFoundException, and the repository are illustrative application types. Implement them according to the project's identity and persistence design. Ensure the access check cannot be bypassed by changing a URL parameter, request body, or hidden form field.

9. Authentication in Servlet-Based Applications

In traditional Jakarta Servlet applications, authentication may be provided through container-managed security, a framework such as Spring Security, or a carefully designed custom mechanism. Prefer a mature framework or container feature over implementing a custom security filter from scratch.

9.1 Session-based flow

1. The user submits a login form over HTTPS.
2. The server validates the credentials against a trusted account store.
3. On success, the server establishes an authenticated session.
4. The browser sends the session cookie on later requests.
5. The server verifies the session and authorizes each protected operation.
6. On logout, the server invalidates the session and clears the relevant cookie.

9.2 Session handling example

// Illustrative servlet fragment after credentials
// have been verified by a trusted authentication service.
HttpSession oldSession = request.getSession(false);

if (oldSession != null) {
    oldSession.invalidate();
}

HttpSession session = request.getSession(true);
session.setAttribute("userId", authenticatedUser.getId());
session.setAttribute("role", authenticatedUser.getRole());

// Configure session cookies centrally to use Secure,
// HttpOnly, and an appropriate SameSite policy.

This fragment is not a complete login implementation. Credential verification, session-fixation protection, CSRF protection, cookie configuration, exception handling, and access checks must also be implemented. In framework-managed applications, use the framework's authentication flow rather than duplicating its session logic.

10. Session-Based vs. Token-Based Authentication

Choose the model according to the client type, deployment architecture, and threat model. A token is not automatically safer than a session, and JWTs should not be used merely because an application has multiple services.

11. Password Security and Account Protection

Password security is one of the most important parts of authentication. Passwords must never be stored in plaintext, embedded in source code, or written to application logs. Spring Security provides the PasswordEncoder interface for secure password verification and storage. Read the Spring Security Password Storage Documentation.

11.1 Password security practices

• Use a modern adaptive password-hashing algorithm, such as Argon2id or bcrypt, with an appropriate work factor.
• Allow long passphrases and avoid unnecessarily restrictive password composition rules.
• Use a password manager and encourage unique passwords for every account.
• Implement secure password-reset tokens that are random, short-lived, single-use, and invalidated after use.
• Do not reveal whether a username or email address exists during login or account recovery.
• Apply rate limiting and monitoring to reduce brute-force and credential-stuffing attacks.
• Require multi-factor authentication for administrators and other high-risk accounts.
• Support secure password-hash upgrades when algorithms or work factors change.

11.2 Verify passwords with PasswordEncoder

import org.springframework.security.crypto.password.PasswordEncoder;

public class PasswordService {

    private final PasswordEncoder passwordEncoder;

    public PasswordService(PasswordEncoder passwordEncoder) {
        this.passwordEncoder = passwordEncoder;
    }

    public String encodePassword(String rawPassword) {
        return passwordEncoder.encode(rawPassword);
    }

    public boolean verifyPassword(
            String rawPassword,
            String storedHash) {
        return passwordEncoder.matches(rawPassword, storedHash);
    }
}

The example demonstrates password hashing and verification only. A complete registration flow must also validate the password, enforce account policies, handle duplicate accounts safely, and store the hash through a secure persistence layer.

12. Multi-Factor Authentication (MFA)

Multi-factor authentication requires users to prove their identity using more than one type of factor. It helps reduce the risk of account compromise when a password is stolen.

MFA implementation flow

1. The user submits their primary credentials.
2. The server verifies the credentials and determines whether MFA is required.
3. The application creates a short-lived, limited authentication state rather than granting full access immediately.
4. The user completes a second factor, such as an authenticator challenge or hardware security-key verification.
5. The server validates the response, enforces attempt limits, and checks expiry and replay protections where applicable.
6. Only after successful verification does the application establish the fully authenticated session or issue the appropriate token.

Prefer phishing-resistant methods such as passkeys or hardware security keys where practical. SMS-based one-time codes can provide an additional barrier but are more vulnerable to attacks such as SIM swapping. Recovery codes and lost-device procedures must also be protected.

13. OAuth 2.0 and OpenID Connect

Enterprise applications may rely on an external identity provider instead of directly collecting and managing user passwords. OAuth 2.0 is primarily an authorization framework for delegated access, while OpenID Connect (OIDC) adds an identity layer for authentication.

13.1 Important terms

• Identity Provider (IdP): The system that authenticates users and provides identity information.
• Client: The application requesting authorization or authentication.
• Authorization Server: The component that issues tokens and manages authorization grants.
• Access Token: A credential presented to an API to access permitted resources.
• ID Token: An OIDC token containing claims about the authentication event and user identity.
• Refresh Token: A credential that may be exchanged for new access tokens, subject to the provider's policies.

13.2 Authorization Code flow with PKCE

1. The client redirects the user to the identity provider.
2. The user authenticates with the identity provider and completes any required MFA.
3. The identity provider redirects the user to the registered callback URI with an authorization code.
4. The client exchanges the code using the PKCE verifier and the appropriate client authentication, if applicable.
5. The client validates the resulting authentication information according to the protocol and library requirements.
6. The client uses an access token to call protected APIs, which independently validate the token and authorize the requested action.

Use Authorization Code with PKCE for modern browser, mobile, and other applicable clients. Validate issuer, audience, signature, expiry, and other required claims. Never accept an ID token as an API access token without an appropriate, explicitly designed protocol contract.

13.3 JWT security considerations

• Accept tokens only from trusted issuers and with expected audiences.
• Allow only approved signing algorithms and validate the signature using trusted keys.
• Check token expiry and relevant not-before and issuer claims.
• Keep signing keys and client secrets out of source code and version control.
• Use short-lived access tokens and a planned revocation or rotation strategy.
• Do not put passwords, private keys, or unnecessary sensitive data into token claims.
• Never assume that a decoded JWT is valid simply because its payload can be read.

14. Protecting Against CSRF, XSS, and SQL Injection

14.1 Cross-Site Request Forgery (CSRF)

CSRF occurs when a malicious site causes a user's browser to send an unwanted request to an application where that user is already authenticated. It is especially relevant when authentication depends on browser cookies.

• Keep CSRF protection enabled for browser-based applications using cookie-backed authentication.
• Include and validate CSRF tokens on state-changing requests.
• Use appropriate cookie settings, including Secure, HttpOnly, and a suitable SameSite policy.
• Do not use GET requests for state-changing operations such as deleting accounts or making payments.
• Do not disable CSRF protection merely to make a request succeed; evaluate the authentication model and framework guidance first.

Spring Security includes CSRF protection for unsafe HTTP methods by default in its servlet configuration. Read the Spring Security CSRF Documentation.

14.2 Cross-Site Scripting (XSS)

XSS occurs when untrusted content is executed as script in a user's browser. It can lead to data exposure, unauthorized actions, or session compromise.

• Encode output according to its context, such as HTML text, HTML attributes, or JavaScript.
• Use template engines that escape untrusted values by default.
• Avoid inserting untrusted strings into executable JavaScript or unsafe DOM APIs.
• Apply a carefully designed Content Security Policy as an additional defense.
• Keep client-side and server-side dependencies updated.

14.3 SQL Injection

SQL injection occurs when untrusted input is interpreted as part of a database command. Use parameterized queries, prepared statements, or properly configured ORM queries instead of building SQL by concatenating user input.

// Safer JDBC example
String sql =
    "SELECT id, username, password_hash " +
    "FROM app_user WHERE username = ?";

try (PreparedStatement statement =
         connection.prepareStatement(sql)) {

    statement.setString(1, username);

    try (ResultSet resultSet = statement.executeQuery()) {
        if (resultSet.next()) {
            // Retrieve the required account fields.
            // Verify the password using PasswordEncoder.
        }
    }
}

Use the minimum database privileges required by the application. Parameterized SQL prevents input values from being interpreted as SQL syntax, but it does not replace authorization checks or secure database configuration.

15. Role and Permission Management

As enterprise applications grow, assigning every individual permission directly to every user becomes difficult to maintain. A common design assigns permissions to roles and roles to users.

User
  |
  +-- Role: HR
  |      +-- EMPLOYEE_READ
  |      +-- EMPLOYEE_UPDATE
  |
  +-- Role: ADMIN
         +-- EMPLOYEE_READ
         +-- EMPLOYEE_UPDATE
         +-- USER_MANAGE
         +-- ROLE_MANAGE

Recommended design practices

• Follow the principle of least privilege: grant only the permissions needed for a job.
• Separate administrative roles from ordinary business roles.
• Use a consistent naming convention for roles and permissions.
• Validate role assignments on the server; never trust a role supplied by the browser.
• Review privileged accounts periodically and remove access when it is no longer required.
• Record sensitive role changes in an audit trail.
• Consider separation of duties for critical operations such as payments and approvals.

16. Handling Unauthorized Access

Applications should distinguish between unauthenticated requests and authenticated requests that lack permission.

Use consistent error responses that do not expose passwords, stack traces, internal role structures, database details, or other sensitive information. For REST APIs, return a stable error format and an appropriate HTTP status. Browser applications may redirect unauthenticated users to a login page.

17. Logout, Session Expiry, and Account Recovery

17.1 Secure logout

• Invalidate the server-side session or revoke the relevant authentication state when supported.
• Clear the session cookie using matching cookie path and domain settings.
• For token-based systems, use a deliberate token-expiry, revocation, or session-management strategy.
• Do not log users out through a state-changing GET request.
• Consider single sign-out behavior when an external identity provider is used.

17.2 Session timeout

Use both idle and absolute session timeouts where appropriate. High-risk applications may require re-authentication before sensitive operations. Session duration should reflect the application's threat model and business requirements rather than being unlimited by default.

17.3 Password reset workflow

1. Accept the account recovery request without revealing whether the account exists.
2. Generate a cryptographically secure, unpredictable, single-use reset token.
3. Store a protected representation of the token and set a short expiry.
4. Send the recovery link through a verified channel.
5. Validate the token and allow the user to set a new password securely.
6. Invalidate the token and consider revoking existing sessions or refresh tokens.
7. Notify the account owner and record relevant security events.

18. Security Testing

Authentication and authorization must be tested at both the endpoint and business-service levels. Tests should verify successful access as well as denial of access.

18.1 Example Spring Security test

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.security.test.web.servlet.request
    .SecurityMockMvcRequestPostProcessors.user;
import static org.springframework.test.web.servlet.request
    .MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result
    .MockMvcResultMatchers.status;

@SpringBootTest
@AutoConfigureMockMvc
class AuthorizationTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void employeeCannotAccessAdminEndpoint() throws Exception {
        mockMvc.perform(get("/admin/dashboard")
                .with(user("employee").roles("EMPLOYEE")))
            .andExpect(status().isForbidden());
    }
}

This test assumes that /admin/dashboard is configured to require the ADMIN role and that the test dependencies include Spring Security's test support. The test verifies authorization behavior; it does not replace integration tests for actual password verification, account storage, MFA, or token validation.

19. Common Problems and Troubleshooting

20. Enterprise Authentication and Authorization Best Practices

• Use HTTPS throughout the application and protect traffic between services.
• Prefer a mature security framework or trusted identity provider over custom authentication code.
• Keep authentication separate from authorization and enforce both consistently.
• Apply least privilege to users, service accounts, database users, and administrators.
• Use secure password hashing and never store plaintext passwords.
• Use MFA for privileged accounts and sensitive workflows.
• Protect sessions with suitable cookie settings, timeouts, and session-fixation defenses.
• Retain CSRF protection for browser-based cookie authentication unless a reviewed architecture justifies a different approach.
• Validate tokens rigorously and manage secrets through a secure secret-management system.
• Use parameterized SQL and validate all untrusted input.
• Log security-relevant events while excluding passwords, access tokens, session IDs, and other secrets.
• Apply rate limiting, alerting, dependency updates, security testing, and incident-response procedures.
• Review authorization rules whenever new endpoints, roles, or business workflows are introduced.

21. Practical Project: Employee Management Security Module

Project objective: Implement a secure authentication and authorization layer for an Employee Management System using Java, Spring Boot, Spring Security, and a relational database.

Functional requirements

• Provide a secure login and logout process.
• Store account records and password hashes in a database.
• Support ADMIN, HR, MANAGER, and EMPLOYEE roles.
• Allow administrators to manage users and roles.
• Allow HR users to create and update employee records.
• Allow employees to view only their own permitted information.
• Protect sensitive operations with server-side authorization checks.
• Handle disabled accounts, session expiry, and password recovery.
• Record important security events for auditing.

Suggested project structure

src/main/java/com/example/securityapp/
    config/
        SecurityConfig.java
        PasswordConfig.java
    controller/
        LoginController.java
        EmployeeController.java
        AdminController.java
    service/
        AuthenticationService.java
        EmployeeService.java
        UserService.java
    repository/
        UserRepository.java
        EmployeeRepository.java
    entity/
        AppUser.java
        Role.java
        Employee.java
    security/
        CurrentUser.java
    exception/
        AccessDeniedHandler.java

Implementation steps

1. Create the Spring Boot project and add the web, security, persistence, and database dependencies.
2. Design user, role, and employee tables with suitable constraints.
3. Implement user registration or controlled account provisioning with secure password hashing.
4. Configure authentication using a persistent user store or trusted identity provider.
5. Define URL-level access rules for public, employee, HR, and administrator routes.
6. Add method-level authorization to sensitive business services.
7. Implement record ownership checks so employees cannot access other employees' private data.
8. Configure session security, CSRF protection, logout, and account-recovery flows.
9. Write positive and negative tests for every important role and protected endpoint.
10. Document the access-control matrix and verify it before deployment.

Example access-control matrix

This matrix is an illustrative starting point. Final permissions should be determined by the organization's business rules, privacy requirements, and separation-of-duties policies.

22. Practice Exercises

1. Configure a public home page and protected dashboard using Spring Security.
2. Create ADMIN and EMPLOYEE roles and verify that each role receives the correct access.
3. Replace in-memory accounts with database-backed user authentication.
4. Implement password hashing and password verification using a configured PasswordEncoder.
5. Add a service-level permission check for employee record updates.
6. Write a test that proves a normal employee cannot access an administrator endpoint.
7. Test a request that attempts to access another employee's record by changing the record ID.
8. Verify that browser forms reject invalid or missing CSRF tokens when protection applies.
9. Design a password-reset workflow with token expiry and single-use validation.
10. Document an MFA rollout plan for administrator accounts.

23. Interview Questions and Answers

Q1. What is authentication?

Answer: Authentication verifies the identity of a user or system using credentials such as passwords, passkeys, certificates, or tokens.

Q2. What is authorization?

Answer: Authorization determines which resources and operations an authenticated identity is permitted to access.

Q3. What is the difference between HTTP 401 and HTTP 403?

Answer: HTTP 401 generally indicates missing or invalid authentication credentials. HTTP 403 indicates that the request is not permitted. Browser login flows may redirect unauthenticated users instead of returning 401.

Q4. What is Spring Security?

Answer: Spring Security is a Java security framework that supports authentication, authorization, security filters, session protection, and defenses against common web attacks.

Q5. Why should passwords be hashed?

Answer: Password hashing reduces the damage caused by a credential-store breach because the original passwords are not directly stored. Adaptive password hashes make large-scale guessing more expensive.

Q6. What is the purpose of PasswordEncoder?

Answer: It encodes passwords for storage and verifies submitted passwords against stored hashes without needing to recover the original password.

Q7. What is RBAC?

Answer: Role-Based Access Control grants permissions through roles assigned to users, making access management easier to maintain.

Q8. What is method-level security?

Answer: Method-level security applies authorization rules to service or method invocations, helping protect business operations independently of URL configuration.

Q9. What is CSRF?

Answer: Cross-Site Request Forgery is an attack that tricks a browser into sending an unwanted authenticated request. CSRF tokens and appropriate cookie policies help mitigate it.

Q10. What is the difference between OAuth 2.0 and OpenID Connect?

Answer: OAuth 2.0 is an authorization framework for delegated access. OpenID Connect builds on OAuth 2.0 to provide a standardized authentication and identity layer.

Q11. Why are JWTs not automatically secure?

Answer: A JWT must be validated correctly. Applications must verify its signature, issuer, audience, expiry, and other required claims and must manage signing keys securely.

Q12. What is the principle of least privilege?

Answer: It means granting each user or service only the permissions required to perform its assigned responsibilities.

Q13. How can session fixation be prevented?

Answer: Use framework-supported session-fixation protection and ensure that authentication does not continue to rely on an unsafe pre-authentication session identifier.

Q14. Why is URL-level security alone insufficient?

Answer: Sensitive business methods may be invoked through different routes or internal calls. Service-level checks and resource-specific authorization help enforce access rules consistently.

Q15. How should an enterprise application handle repeated failed logins?

Answer: Apply appropriate rate limiting, monitoring, alerting, and risk-based controls. Avoid policies that make it easy for attackers to lock out other users.

24. Quick Revision Checklist

• Authentication verifies identity; authorization checks permission.
• Use HTTPS and a trusted authentication framework.
• Never store plaintext passwords.
• Use adaptive password hashing and a secure recovery process.
• Define roles and permissions using least privilege.
• Secure URLs and sensitive service methods.
• Verify resource ownership and business-specific access rules.
• Protect sessions, cookies, tokens, and signing keys.
• Use CSRF protection for applicable browser-based flows.
• Validate tokens instead of merely decoding them.
• Test both successful access and denied access.
• Log security events without recording secrets.

25. Conclusion

Implementing authentication and authorization correctly is essential for protecting enterprise Java applications. Authentication establishes who is making a request, while authorization determines what that identity may do. A secure implementation combines a trusted authentication mechanism, appropriate password storage, role and permission management, resource-level access checks, session or token security, and comprehensive testing.

Spring Security provides many of the building blocks needed for these controls, but the application team must define appropriate policies and configure them according to the business context. Security should be treated as an ongoing engineering responsibility, including regular reviews, dependency updates, monitoring, and testing.

Additional Learning Resources

• Explore Advanced Java Training at JustAcademy
• Register for a JustAcademy Course Demo
• Visit the JustAcademy Homepage
• Spring Security Official Reference
• Spring Security HTTP Request Authorization
• Spring Security Password Storage
• Spring Security CSRF Protection