[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_59일차_"세션, JWT"

🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [59]일차

🚀59일차에는 Spring Security에서 세션을 설정하는 방법과 세션을 관리하는 방법인 JWT에 대해 실습할 수 있었다.

학습 목표 : JWT의 개념과 사용 방법에 대해서 배우고 인코딩, 디코딩 과정 실습

학습 과정 : 회고를 통해 작성

---

CustomUserDetailsService

• Spring Security의 사용자 인증 정보를 관리하는 UserDetailsService 인터페이스를 직접 커스텀해서
  구현한 사용자 인증 정보 로드 클래스

.csrf(csrf -> csrf.disable())
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/myinfo","/signup","/userreg", "/userreg_role","/loginform","/").permitAll()
                        .requestMatchers("/welcome","/shop/**").hasRole("USER")
                        .requestMatchers("/admin/**").hasRole("ADMIN")
                        .anyRequest().authenticated()
                );

• .authorizeHttpRequests( … ) : 인증했을 경우의 Http 요청에 대한 설정 부분을 담당
• .requestMatchers() : 특정 요청 페이지들을
• .permitAll() : 지정한 페이지들을 허용
• .hasRole() : 특정 권한이 페이지에 접근하는 것을 허용
• . anyRequest().authenticated() : 그 외 페이지들에 대해서는 “인증”이 되어야만 보여줌
  
  
• CsrfFilter : CSRF공격으로부터 보호
• UsernamePasswordAuthenticationFilter : 폼 로그인 처리
• BasicAuthenticationFilter : HTTP 기본 인증 처리
• AuthorizationFilter : 요청의 권한 부여 처리

---

세션 매니지먼트 Session Management

• 로그인 후 시크릿모드로 같은 URL에 접근하면 이전에 로그인했던 정보가
  그대로 가져와져서 보여지고 있는 것을 확인 가능
• 보안을 위해 세션을 설정하여 로그인 허용을 설정해줄 수 있음

http
        .formLogin(form ->form
                .loginPage("/loginform")
                .loginProcessingUrl("/login")
                .defaultSuccessUrl("/welcome")
        )
        .logout(logout ->logout
                .logoutUrl("/logout")
                .logoutSuccessUrl("/")
        )
        .sessionManagement(session -> session
                .maximumSessions(1) // 동시 접속 가능한 세션 수 설정
                
        )
        .userDetailsService(customUserDetailsService);

• 기존 http 코드에 Session Management 속성을 넣어서 세션을 설정
  
  
• .maximumSessions(1) : 동시 접속 가능한 세션 수 설정
  ex. 3이면 3개 이상 세션부터는 로그인 유지를 하지 않음
  
  
• .maxSessionsPreventsLogin(false) : 동시에 로그인이 들어왔을때 누군가를 차단해야할 것
  기본값은 false → // 첫번째 로그인된 사용자가 차단됨
  true로 바꾸게되면 → 두번째 로그인 사용자부터 차단됨

---

Spring Security 세션

• Spring Security는 기본적으로 인증, 인가를 관리하고 인증에 필요한 정보는 주로 세션에 저장
• 사용자가 로그인하면 사용자의 인증상태, 사용자 권한정보가 세션에 저장되는 것
• 세션에 저장된 정보로 서버가 사용자를 식별하고 인증상태를 유지할때 사용
  ex. jsessionid가 쿠키로 저장되어있을때 서버는 세션을 식별하고
  세션에 저장된 정보를 이용하여 사용자를 인증하고 관리
  
  
• 세션에 저장되는 주요 클래스 : SecurityContext (현재 사용자의 인증정보와 권한정보를 담음)
• SecurityContext는 SecurityContextHolder를 통해 접근하고 관리

---

JWT

• 문자열로써 JSON객체를 사용하여 정보를 전달
• Json Web Token(=JWT) : 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰
• JWT자체는 인증/인가와는 관련이 없음
• 즉 JSON 객체를 사용하여 정보를 저장하고 디지털 서명을 통해 검증한다.
• JWT 구성요소 : Header(헤더) + Payload(페이로드 : 실제 저장해야할 정보) + Signature(서명 : 검증하는 용도)
  
  
• JWT는 세션을 저장하는 것이 아니라, 인증 정보를 포함한 토큰을 제공하는 방식
• 즉, JWT 자체가 세션 정보를 저장하는 것은 아니지만, 로그인 상태를 유지하는 데 활용
  ➡️JWT는 클라이언트에 저장되며, 로그인 상태를 유지하는 데 사용될 수 있음

---

JWT Header

• JWT 타입과 해싱 알고리즘 정보가 담김

 

JWT Payload

• 가장 중요한 부분으로 실제로 전송할 데이터가 담김
  ⭐클레임(claim)이라 불리는 정보들이 포함됨
  
  
• 클레임의 3가지 유형
  - Registered claims : 특정한 정보를 제공하기 위해 사전에 정의된 클레임들 (발행자, 만료시간, 주체)
  - Public claims : 사용자 정의 클레임으로 충돌을 피하기 위해 URI형식으로 작성
  - Private claims : 애플리케이션에서 사용할 수 있는 클레임

 

JWT Signature

• Header, Payload의 내용을 인코딩
• 비밀키를 사용하여 서명 : 메시지가 변경되지 않았음을 확인, 검증하는데 사용

 

JWT 작동방식

1. 사용자로그인
2. 서버의 JWT 생성
3. 사용자에게 반환
4. JWT는 클라이언트의 저장소에 저장
5. 클라이언트는 JWT를 서버에 전달
6. 서버는 JWT의 서명을 통해 해당 토큰이 유효한지 검증하고 클라이언트가 요청한 작업을 수행

---

JWT 토큰 종류

• Access Token : 시간을 짧게 만듦 (* 30분 정도 : 짧게 설정할수록 보안은 좋지만 서버에 부하 가능성 높아짐)
• Refresh Token : 시간을 길게 만듦 (* 한달, 1년 등등 : DB에 저장해서 관리하게함)

일반적으로는 리프레시 토큰을 가지고 있다가 특정 시간마다 액세스 토큰을 발급시키는 방식으로 사용

ex. 이메일로 “현재 어느 위치에서 로그인 되었습니다. 본인이 맞으시면 예, 아니시면 아니오를 선택하세요” 받았을때
아니오를 선택하게되면 서버가 갖고 있던 Refresh Token 삭제

❓Refresh Token을 삭제하는 이유

1. 보안 강화
➡️Refresh Token은 새로운 Access Token을 발급할 수 있는 중요한 키이므로
탈취되었을경우 다른 사용자가 장기간 로그인하는 것을 방지

따라서 본인이 아니라면 Refresh Token을 즉시 삭제하여 더 이상 새로운 Access Token이 발급되지 않도록 함

2. 재로그인 유도
➡️Refresh Token이 삭제되면 사용자는 다시 로그인해야 하므로, 다른 사용자가 지속적으로 시스템에 접근하는 걸 방지

---

JWT 장단점

• 장점 : 간단하고 분산 환경 지원 가능
• 단점 : 정보를 포함하면서 크기가 커질 수 있고 보안문제 발생 가능성 (=토큰탈취가능성)

---

폼 로그인 과정에서 세션

1. 클라이언트가 웹에서 "폼 정보에 따라" 로그인
2. 세션에 정보가 저장
3.세션정보는 서버가 관리함

---

❓서버가 여러대 일때의 문제점

사용자가 폼에 로그인한 정보가 서버에 저장되려고할때 사용자의 요청을
여러 서버로 분산시키는 역할을 “로드 밸런서”가 담당함

폼 로그인 방식에서는 사용자가 로그인하면 세션(Session) 을 생성하고, 이 세션 정보를 서버에서 관리

로드 밸런서 (Load Balancer) : 여러 대의 서버가 있을 때 요청을 분산시켜주는 역할

✅해결 방법 : 세션 관리 방법 3가지

1. Sticky Session (고정 세션) 사용
➡️로드 밸런서가 한 번 로그인한 사용자의 요청을 항상 같은 서버로 보내는 방식
➡️특정 서버에 장애가 발생하면 세션이 사라지는 단점

2. 세션을 외부 저장소에 저장 (DB 또는 Redis 활용)
➡️여러 서버에서 세션을 공유할 수 있도록, 세션을 Redis, Memcached, DB 등에 저장
➡️서버가 달라져도 세션 정보가 유지되므로 안정적

3. JWT (JSON Web Token) 사용
➡️서버에 세션을 저장하는 대신, JWT를 활용하여 클라이언트 측에서 인증 정보를 유지할 수 있음
➡️서버 간 세션 동기화 문제가 사라지고, 로드 밸런싱이 자유로워짐\

정리하자면
서버가 여러 대일 경우, 세션 데이터가 각 서버에 개별적으로 저장되면 세션 불일치 문제가 발생 가능
이때 로드 밸런서는 요청을 분산시킬 뿐, 세션을 직접 관리하지는 않으므로 JWT 같은 방식으로 해결해야함

JWT는 세션을 서버가 관리하지 않고, 토큰을 클라이언트에서 관리하도록 하는 기술임

보안에 취약할 수 있어 세션을 클라이언트가 아닌 서버가 가졌던 기존의 방법에서 
클라이언트 측에 “보안된 상태로” 인증 정보를 저장하는 것이 JWT 기술인 것

• 이 인코딩된 정보를 “디코딩 De-coding”으로 풀어내어 다시 값을 얻어낼 수 있을 것
• JWT 자체는 암호화되지 않으며, 누구나 디코딩하여 내용을 볼 수 있으므로 중요한 정보(ex. 비밀번호)는
  JWT에 포함하지 않는 것이 원칙
  
  
• JWT에는 서명(Signature) 이 포함되어 있어,
  비밀키(Secret Key) 또는 공개키/개인키(Public/Private Key) 로 서명을 검증
  
  
• 이러한 서명으로 JWT가 위조되지 않았음을 확인하는데 즉, JWT의 내용을 변경하려면
  서명(Signature)도 함께 변경해야 하므로, 비밀키 없이 위조는 불가능함 (비밀키는 서버가 가지고 있음)

---

세션 공유의 단점

• 여러 외부 저장소에서 가져오도록 구현이 되어있으면 세션 데이터를 가져오는 과정에서
  네트워크 지연이 발생할 수 있음
• 외부 저장소에 세션 데이터를 저장하게되면 보안 문제가 발생할 가능성이 있음
• 성능 문제로 매우 빠른 인메모리 세션 스토어에 비해 외부 저장소는 느릴 수 있음
  또한 데이터베이스에 저장된 세션은 DB의 부하로 성능 저하 가능성이 있음

---

JWT에서 자바 사용

• application.yml에 비밀 키, 리프레시 키 추가 (32비트 정도 길이로 설정)
• SignatureAlgorithm 생성

• 숫자가 많을수록 더 많은 비트 수를 차지할 수 있게됨

public static void main(String[] args) {
    SecretKey secretKey = Keys.secretKeyFor(SignatureAlgorithm.HS256);

    String jwt = Jwts.builder()
            .setIssuer("juunb-app") // 어디서 사용하는 것인지 설정
            .setSubject("juunb123")
            .setExpiration(new Date(System.currentTimeMillis() + 36000)) // 만료 시간 설정 (ms 기준)
            .claim("role", "ADMIN")
            .signWith(secretKey) // SIGN을 만듦 (secretKey를 이용해서 만듦)
            .compact();

    System.out.println(jwt); // 토큰 출력해보기
}

출력 : 토큰 {eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqdXVuYi1hcHAiLCJzdWIiOiJqdXVuYjEyMyIsImV4cCI6MTc0MTE1MzczMSwicm9sZSI6IkFETUlOIn0.Tw6kHrKKc2BmJCrZ3Cks4FTSwDewEnlDCKa2wv0XLBo}

• 토큰을 jwt.io와 같은 페이지를 통해 디코딩해보면 설정해놨던 정보들이 출력되고 있는 것을 확인 (payload 부분)

---

Decoding 디코딩

• 디코딩 하는 과정을 직접 작성할 수도 있음

// JWT 파싱, 검증 파트
Claims claims = Jwts.parserBuilder()
        .setSigningKey(secretKey)
        .build()
        .parseClaimsJws(jwt)
        .getBody();

log.info("[Decoding Result] - Expiration Time : {}", claims.getExpiration());
log.info("[Decoding Result] - Subject : {}", claims.getSubject());
log.info("[Decoding Result] - Role : {}", claims.getAudience());

---

SecretKey를 만드는 방법 2가지

// 1. 알고리즘으로 secretKey를 만드는 방법
//        SecretKey secretKey = Keys.secretKeyFor(SignatureAlgorithm.HS256);

// 2. 사용자 정의 secretKey를 만드는 방법 - 적절한 SecretKey(32바이트 이상)를 수동 생성
String secret = "abcdefghijklmnopqrstuvwxzy123456789012"; // 최소 32바이트 유지
byte[] bytes = secret.getBytes(StandardCharsets.UTF_8);
SecretKey secretKey = Keys.hmacShaKeyFor(bytes);

1. 알고리즘으로 SecretKey를 만드는 방법

➡️32바이트(256비트) 이상의 키를 내부적으로 알아서 설정
➡️SecretKey를 자동으로 생성하기 때문에 편리하지만, 고정된 값을 유지하기 어려움

➡️단점 : SecretKey가 실행할 때마다 달라질 수 있음
- JWT 서명을 검증 시 같은 SecretKey가 필요하므로, 일정한 키를 유지해야 함

2. 사용자 정의 SecretKey를 만드는 방법

➡️SecretKey를 직접 정의한 문자열을 사용하여 생성
➡️고정된 키를 사용하므로, 서버가 재시작되어도 같은 SecretKey로 JWT를 검증 가능

➡️장점 : application.yml 또는 환경 변수(.env)에 저장하여 관리 가능
서버가 재시작되더라도 같은 SecretKey를 사용하여 JWT 서명을 검증할 수 있음

➡️단점 : SecretKey를 직접 관리해야 함 (보안 취약)

---

환경변수 추가 application.yml (SecretKey, RefreshKey)

jwt:
  secretKey: 12345678901234567890123456789012
  refreshKey: 12345678901234567890123456789012

 

JwtTokenizer 클래스

• JWT 토큰을 관리할 클래스, JWT 토큰을 편리하게 사용하기 위한 Util 클래스

// JWT토큰을 편하게 사용하기 위한 Util 클래스
@Component
public class JwtTokenizer {
    private final byte[] accessSecret;
    private final byte[] refreshSecret;

    // 이 accessSecret과 refreshSecret을 환경변수 파일 (application.yml)에서 꺼내서 사용할 것
    public JwtTokenizer(@Value("${jwt.secretKey}") String accessSecret, @Value("${jwt.refreshKey}") String refreshSecret) {
        this.accessSecret = accessSecret.getBytes(StandardCharsets.UTF_8); // String -> byte로 변환
        this.refreshSecret = refreshSecret.getBytes(StandardCharsets.UTF_8); // String -> byte로 변환
    }
}

•  @Value("${jwt.secretKey}") String accessSecret
  ➡️@Value 를 사용하여 환경변수 파일 (application.yml)에 있는 값에 접근 ($ { } 활용)
  
  
• getBytes(StandardCharsets.UTF_8);
  ➡️String -> byte로 변환

 

JwtTokenizer - createToken() 메소드 추가

// 토큰에 포함할 정보를 함께 만듦
private String createToken(Long id, String email, String name,
                           String username, List<String> roles,
                           Long expire, byte[] secretKeys){
    Claims claims = Jwts.claims().setSubject(email);

    // 필요한 정보들 저장
    claims.put("username", username);
    claims.put("name", name);
    claims.put("userId", id);
    claims.put("roles", roles);

    return Jwts.builder()
                .setClaims(claims)
                .setIssuedAt(new Date())
                .setExpiration(new Date(new Date().getTime()+expire))
                .signWith(getSigningKey(secretKeys))
                .compact();
}

• ❓@Component 사용 이유
  ➡️JwtTokenizer 클래스를 Spring이 자동으로 생성하고 관리하도록 함
  
  JWT 관련 기능을 제공하는 공통 유틸 클래스로써 여러 곳에서 재사용될 수 있도록 함
  (= 매번 객체를 생성하지 않고, Spring이 한 번만 생성하고 관리)
  
  
• Claims claims = Jwts.claims().setSubject(email);
  ➡️id, name 등 원하는 것을 넣어주면 됨
  ➡️가급적이면 고유한 식별자값 (중복 X)을 넣어주는 것이 좋음
  
  ex. 해당 Subject의 키 값 (만약 이메일 인증 서비스면 이메일을 넣어줌)
  
  ➡️Claims: JWT의 페이로드(payload) 부분을 의미
  setSubject(email): 토큰의 주제(Subject)를 이메일로 설정
  
  
• .setExpiration(new Date(new Date().getTime()+expire))
  expire : 1000ms (1 sec) >> 1000 * 60 * 60 = 1 hour
  
  
• .signWith(getSigningKey(secretKeys))

private static Key getSigningKey(byte[] secretKey){
    return Keys.hmacShaKeyFor(secretKey);
}

• 정의한 메소드 getSigninKey() 를 이용해 수행
• JWT의 서명을 위한 SecretKey 객체 생성
  createToken()에서 사용하여 JWT의 Signature(서명) 부분을 생성
  
  
• signWith() 메서드는 Key 객체가 필요하므로,→ 바이트 배열(byte[]) → SecretKey 객체로 변환
• 즉, getSigningKey() 메소드 : 서명을 위한 SecretKey 객체를 반환

 

정리하자면

1. SecretKey를 application.yml에서 가져와 저장
2. createToken()에서 JWT의 Payload(사용자 정보) 설정
3. JWT의 발급 시간, 만료 시간 설정
4. getSigningKey()를 사용해 SecretKey 객체 생성
5. JWT의 서명(Signature) 추가
6. 마지막.compact()를 통해 JWT 문자열 반환

---

Access Token, Refresh Token 재사용

public static final Long ACCESS_TOKEN_EXPIRE_COUNT = 1000L * 60 * 30; // 액세스 토큰 유지시간 30분
public static final Long REFRESH_TOKEN_EXPIRE_COUNT = 1000L * 60 * 60 * 24 * 7; // 액세스 토큰 유지시간 7일

• 장점 : 토큰 만료 시간이 고정되어 있어 매번 다르게 변하지 않음

 

Access Token, Refresh Token 생성 메소드

// 액세스 토큰 생성
public String createAccessToken(Long id, String email, String name,
                                String username, List<String> roles){

    return createToken(id, email, name, username, roles, ACCESS_TOKEN_EXPIRE_COUNT, accessSecret);
}

// 리프레시 토큰 생성
public String createRefreshToken(Long id, String email, String name,
                                String username, List<String> roles){

    return createToken(id, email, name, username, roles, REFRESH_TOKEN_EXPIRE_COUNT, refreshSecret);
}

•  두 메소드는 createToken() 메서드를 호출하여 JWT를 생성
• Access Token(AT) : API 요청을 보낼 때 인증 용도로 사용 (짧은 시간 유지)
• Refresh Token(RT) : Access Token이 만료되었을 때 새로 발급받는 용도로 사용 (더 긴 시간 유지)
  
  
• createToken() 메소드에서는
  ➡️토큰 생성의 핵심 로직을 담당
  ➡️공통적인 JWT 생성 과정을 캡슐화하여 코드 중복을 줄임

 

Main 테스트

public static void main(String[] args) {
    JwtTokenizer jwtTokenizer = new JwtTokenizer(
            "12345678901234567890123456789012",
            "12345678901234567890123456789012");

    String accessToken = jwtTokenizer.createAccessToken(1L, "test@test.com", "test", "testuser", Arrays.asList("ROLE_USER"));

    log.info("[ACCESS TOKEN] : {}", accessToken);
}

➡️출력 : [ACCESS TOKEN] : eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0Q……

---

🚀회고 결과 :
이번 회고에서는 세션에 대한 개념을 다시 학습하고 Spring Security에서의 적용과 JWT 사용을 다양한 예제로 접할 수 있었다.

- Session Management를 통한 세션 설정
- JWT로 AccessToken, Refresh Token 생성

느낀 점 : 
이메일로 전송되는 "로그인 확인 메일"과 기존 브라우저에서 "새 탭"을 열었을때도 로그인이 지속되었던 것이
세션과 관련이 있다는 것을 알 수 있었다.
시크릿모드에서도 세션이 유지되는 것을 확인할 수 있었고 이를 해결하기 위해 Session Management로 세션을 설정할 수 있었다.

향후 계획 : 

- JwtTokenizer의 토큰 생성 과정 학습
- REFRESH TOKEN 생성해보기