JWT Lesson

Notebook Link wget ___

Backend Repository Link git clone

Why do you need JWT

Certain features in your application need to be restricted or require some sort of authentication mechanism. For example, a user information database should only be accessed by administrators as it can contain sensitive information. Certain actions also need to be restricted such as deleting, updating, and creating new records. Additionally, different actions may be attributed to different roles.

What is JWT (AKA “JOT”)

★ JWT stands for **JSON Web Token**.

JWT allows information, in our case authentication roles, to be securely shared between an applications frontend and backend server as a JSON object .

Compact = Because of its size, it can be sent through an URL, POST parameter, or inside an HTTP header. Additionally, due to its size its transmission is fast. [will discuss payload later]

Self-contained = The payload contains all the required information about the user, to avoid querying the database more than once.

What is a JWT Token

JWT is represented as JSON objects, these objects contain information about the user. JWT are supposed to be compact (should be easy to send between 2 parties). This is useful in the context of web development. When data needs to be moved efficiently.

[by looking in the JwtTokenUtil.java]

JWT mainly has 3 different parts:

  1. Header
//header example
{
  "alg": "HS256",
  "typ": "JWT"
}
  1. Payload
//payload example
{
    //subject
    "sub": "1234567890",
    "name": "Tanisha Patel",
    "admin": true
}
  1. Signature

JWT are commonly used in authentication, when the user logs in and gets a JWT, sent to the request to authenticate said user. Servers can verify a token’s authenticity by checking the signature, if valid then the server can trust the information in the token.

//example using the HMAC SHA 256 algorithm
HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret)

Screenshot 2023-12-13 at 4 12 49 PM

Web Tokens

When a user logs in a **JSON Web Token** is returned. Tokens are basically credentials so they need to be protected

★ Should not keep tokens longer than required

★ Should not store data in local storage

Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:

Authorization: Bearer <token>

★ if you send JWT tokens through HTTP headers, you should try to prevent them from getting too big. (some servers don’t accept more than 8KB in headers)

Alternative solution » Auth0 Fine-Grained Authorization.

Instead of adding all the details into a large JWT you can keep the tokens smaller and use Auth0 to check more detailed rules and premissions. Instead of having all the acess information in each request, check Autho0 to see if the user has the right permissions, only fetch the necessary details when required, reducing the data transfer overhead.

Screenshot 2023-12-13 at 4 08 15 PM

1.★ The application or client requests authorization to the authorization server. This is performed through one of the different authorization flows. For example, a typical OpenID Connect compliant web application will go through the /oauth/authorize endpoint using the authorization code flow.

2.★ When the authorization is granted, the authorization server returns an access token to the application.

3.★ The application uses the access token to access a protected resource (like an API).

Don’t put secret information within token > with signed tokens all info contained within token is exposed to userer/other parties but they can’ change it.

Benefits of JWT

Some benefits of JSON Web Tokens (JWT) over Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML):

Asymmetric Signing:

JWT: Supports asymmetric signing using a public/private key pair, providing a more robust security model.

SWT: Limited to symmetric signing with HMAC, which may have implications for key management and security.

Versatility in Key Usage:

JWT: Allows the use of various key types, including X.509 certificates, enhancing flexibility in key management strategies.

SWT: Primarily relies on shared secrets for signing, limiting the range of available key types.

Ease of Implementation:

JWT: Typically considered easier to implement due to its simpler structure and support for common web development libraries.

SWT and SAML: May involve more complex implementations, especially in the case of XML-based SAML tokens.

Compatibility with Modern Web Standards:

JWT: Aligns well with modern web development practices, RESTful APIs, and JSON-based communication, making it a natural fit for contemporary applications.

SWT and SAML: May be perceived as more traditional or heavyweight, with SAML using XML, which could be less favorable in certain contexts.

Token Size and Efficiency:

JWT: Typically has a more compact size due to its JSON format, leading to more efficient transmission and reduced overhead.

SWT and SAML: May have larger token sizes, especially in the case of XML-based SAML, potentially impacting network performance.

Community Adoption:

JWT: Enjoying widespread adoption in the developer community, with extensive support in libraries, frameworks, and platforms.

SWT and SAML: While still used in various scenarios, they may not be as widely adopted or preferred in modern web development.

Standardization and Interoperability:

JWT: Benefits from standardized specifications, promoting interoperability between different systems and services.

SWT and SAML: While standardized, may face challenges in terms of interoperability and compatibility in diverse environments.

However, between these three (JWT, SWT, and SAML) depends on requirments of application, security concerns, and overall structure of system. [each one has special uses can suitable depending on the case]

Anatomy of JWT Folder

Open the cloned backend »

src/main > spring_portfolio > mvc > jwt

JwtApiController.java

Maps the authentication token creation method to the “/create” endpoint. Validating email and password and if valid then generates the JWT token for credentials.

JwtAuthenticationEntryPoint.java

Implementing AuthenticationEntryPoint and overriding the commence function to specify what to do when a user is not authenticated, return unauthorized error.

JwtRequestFilter.java

Extend Spring Web Filter using OncePerRequestFiler class and overrides doFilterInternal function so requests sent to server are processed through function. Function then checks if JWT token is valid and sets Authentication to specify current user is authenticated.

JwtTokenUtil.java

Contains utilities/functions that are needed to generate JWT tokens and get information like email from JWT tokens to make sure JWT token is valid

Unauthenticated User Redirect

In the context of JWT (JSON Web Tokens) in Java, the concept of unauthenticated user redirect typically involves handling situations where a user tries to access a protected resource without proper authentication. JWT is commonly used for authentication and authorization purposes in web applications.

Here’s an explanation of how unauthenticated user redirect might be implemented in Java with JWT:

  1. Authentication Process:
  2. Handling Unauthenticated Users:
  3. Redirect Mechanism:
  4. Java Implementation:

Here’s a simplified example using Spring Security:

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/protected-resource/**").authenticated() // authentication for "protected resources"
                .anyRequest().permitAll() // any request NOT to protected resources is allowed
                .and() 
            .formLogin()
                .loginPage("/login") // Redirect to the login page for unauthenticated users
                .permitAll() 
                .and()
            .logout()
                .permitAll();
    }

    // Other configurations, userDetailsService, etc.
}
  1. Login Controller:
@Controller
public class LoginController {

    @GetMapping("/login")
    public String showLoginForm() {
        return "login"; // Render the login page
    }

    // Handle form submission and authentication here
}

What Happens When you aren’t Logged In

When a user is not logged in and tries to access a protected resource (e.g., /person/authenticate or /human/authenticate), they will be redirected to the login page (/login). This redirection is typically handled by the security configuration in your Spring application. In the provided code, the redirection is not explicitly shown, but it’s assumed that there is a login page or endpoint where users are redirected for authentication.

In the JwtAuthenticationEntryPoint class, the commence method is called when an unauthenticated user tries to access a secured resource. It sends an unauthorized response (HTTP 401) with the message “Unauthorized.”

JwtAuthenticationEntryPoint.java

@Component
public class JwtAuthenticationEntryPoint implements AuthenticationEntryPoint {

    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException) throws IOException {

        // When an unauthenticated user tries to access a secured resource
        // Send an unauthorized response (HTTP 401) with the message "Unauthorized"
        response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Unauthorized");
    }
}

Explanation:

This class is part of the authentication flow and handles the entry point for unauthenticated requests.

JwtRequestFilter.java

Popcorn Hack: Think back to your mini-project. What kind of pages did you have that could’ve required login? Use the JWT code given in the backend and show in the empty code cell below how you would implement it:

@Component
public class JwtRequestFilter extends OncePerRequestFilter {

    // ... (other autowired dependencies)

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {

        // Extract JWT token from the cookie in the request
        final Cookie[] cookies = request.getCookies();
        String username = null;
        String jwtToken = null;

        // Check if cookies are present in the request
        if (cookies != null) {
            for (Cookie cookie : cookies) {
                if (cookie.getName().equals("jwt")) {
                    jwtToken = cookie.getValue();
                }
            }

            // If a JWT token is found, attempt to validate and extract username
            if (jwtToken != null) {
                try {
                    username = jwtTokenUtil.getUsernameFromToken(jwtToken);
                } catch (IllegalArgumentException e) {
                    System.out.println("Unable to get JWT Token");
                } catch (ExpiredJwtException e) {
                    System.out.println("JWT Token has expired");
                } catch (Exception e) {
                    System.out.println("An error occurred");
                } catch (Duplication)
                }
            }
        }

        // If no valid JWT token is found or an error occurs, the user remains unauthenticated

        // Continue with the filter chain
        chain.doFilter(request, response);
    }
}
@Component
public class JwtRequestFilter extends OncePerRequestFilter {

    // ... (other autowired dependencies)

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {

        // Extract JWT token from the cookie in the request
        final Cookie[] cookies = request.getCookies();
        String username = null;
        String jwtToken = null;

        // Check if cookies are present in the request
        if (cookies != null) {
            for (Cookie cookie : cookies) {
                if (cookie.getName().equals("jwt")) {
                    jwtToken = cookie.getValue();
                }
            }

            // If a JWT token is found, attempt to validate and extract username
            if (jwtToken != null) {
                try {
                    username = jwtTokenUtil.getUsernameFromToken(jwtToken);
                } catch (IllegalArgumentException e) {
                    System.out.println("Unable to get JWT Token");
                } catch (ExpiredJwtException e) {
                    System.out.println("JWT Token has expired");
                } catch (Exception e) {
                    System.out.println("An error occurred");
                }
            }
        }

        // If no valid JWT token is found or an error occurs, the user remains unauthenticated

        // Continue with the filter chain
        chain.doFilter(request, response);
    }
}

Explanation:

This class is crucial for validating and processing JWT tokens in each incoming request. If a valid token is present, it sets the user’s authentication details in the security context. If not, the user remains unauthenticated.

Live Demo

Take notes in your own words during the live demo as if you’re explaining to someone else how a JWT program can be used.

Notes:

Hacks