99클럽 28일차 TIL: JWT

2024. 5. 1. 11:46개발 공부

728x90
반응형

#1. 오늘의 학습 키워드

Spring에서의 JWT에 대해

  • 현재 사용자 관리 백엔드 측 개발을 맡고 있다.
    • 사용자 관리라 함은 해당 서비스를 사용할 수 있는 유저들의 인증, 권한 정보들에 대한 관리이다.
    • 따라서 사용자 별 ID, PW 관리 및 특정 메뉴에 대한 권한 관리 등에 대한 로직을 개발 중에 있다.
    • 그 중 비밀번호 재설정(찾기) 기능을 개발하다가 인증에 대해 공부하고 싶어졌다.
      • 해당 기능은 이메일로 인증코드를 전송하여, 사용자가 인증코드를 입력하여 일치하는 확인하는 로직 등으로 이뤄져 있는데, 이 때 로그인 후 클라이언트 측에서 획득한 토큰 정보 없이 이루어져야 한다.
        • 로그인 절차 없이 수행 되어야하는 기능이기 때문.
      • 그래서 토큰과 인증 절차에 대해 알아보고 싶어졌다.

#2. 공부한 내용

1. JWT

- Json Web Token. 로그인 인증 기능에서 사용하는 토큰을 만들 때 사용하는 기술
  • Json 객체에 인증에 필요한 정보들이 담겨 있다.
  • 이 정보들은 비밀키로 서명하여 암호화된 토큰으로 발행 된다

1) JWT 프로세스

  • 일반적으로 JWT 로 인증 및 권한 허가를 받는 프로세스는 아래와 같다.
    1. 사용자 → id, pw 입력 (로그인 요청) → 서버
    2. 서버 → 비밀키로 인증 정보 담긴 json 객체 암호화하여 JWT 토큰 생성 및 발급 / 응답 헤더에 담음 → 클라이언트
    3. 클라이언트 → 로컬에 JWT 저장
    4. 추후 API 호출 시: 클라이언트 → 요청 헤더에 JWT 담아서 전송 → 서버
    5. 서버 API 응답 시: 서버 → 헤더에 JWT 확인 → 인증 되면 응답 → 클라이언트
  • 4번 5번 프로세스에서 알 수 있는 건, 매번 통신 때마다 클라이언트는 자신을 인증해야하고, 서버는 검증을 해야한다.
    • 즉 매번 인증이 필요하다는 것.
    • 이는 HTTP 의 특성에 의한 것이다.
      • Connectionless
        • 한 번 통신 일어나면 바로 연결이 끊어짐
      • Stateless
        • 상태를 기억하지 않음
        • 그래서 바로 직전의 동일한 클라이언트와 서버가 성공적으로 요청 - 응답을 했을 지라도, 해당 정보를 기억하지 않기 때문에, 새로운 요청 - 응답에 대해서는 또 새로 인증 과정을 거쳐야한다.

2) JWT 구조

- Header
- Payload
- Signature
  • Header 에서는 아래와 같은 정보를 담고 있다.
    • alg
      • 암호화 알고리즘 종류
    • typ
      • 토큰 타입
  • Payload 은 사용자 정보를 담고 있고, 아래와 같은 구성이다.
    • sub (subject)
      • 토큰 제목
    • aud (audience)
      • 토큰 대상자
    • iat (issued at)
      • 토큰 발급일시
    • exp (expired)
      • 토큰 만료일시
  • Signature
    • Header, Payload의 문자열을 합쳐서 암호화한 값.
    • Header 와 Payload는 복호화하기 쉽지만, Signature는 Header의 alg 에서 선언된 알고리즘과 key 를 이용해 암호화한 값이기에, key 가 없으면 복호화할 수 없다.
      • 보안 상 안전하다.

2. Spring 에서의 JWT

  • Spring 에서 Jwt 를 구현하려면 두 가지 방법이 있다.
    • Jwt-java 라이브러리
    • Spring Security 라이브러리
  • 위 두 가지 방법의 자세한 사용방법에 대해서는 추후 적용을 거치며 글을 써보겠다.
  • 우선 두 가지 방법 모두 아래와 같은 기능을 제공한다.
    • JWT 의 유효기간 설정
    • JWT 추출 및 유효성 검증


#3. 오늘의 회고

  • JWT 는 인증을 위한 기능을 위한 기술로 아래와 같은 장점이 있어 널리 쓰인다.
    • 양방향 암호화 알고리즘을 통한 서명으로 보안 안전성
    • 로컬에 저장하기에 서버 용량에 영향 X
    • 플랫폼 독립적인 인증 방식
  • 물론 단점도 아래와 같이 있다.
    • 토큰 크기가 커지면 트래픽에 영향을 끼칠 수 있다
    • 유효기간이 존재하여, 토큰 만료 시 처리를 구현해야 한다
  • 현재 스웨거로 API 명세서를 작성하고, API 에 대한 개별 테스트(개발 과정에서)를 진행하고 있다.
    • 이때 로그인 API 로 토큰 값을 받고, 해당 토큰 값을 다른 API 호출 전 Authorize 버튼을 통해서 발급 받은 JWT 토큰 값을 입력하고 다른 API 요청을 보낸다.
    • 아직 개발 과정에 있기에, JWT 토큰의 유효기간을 무진장 늘려놓았다.
  • 이렇게 모든 개발에 있어서 계속 JWT 를 사용하여 인증 과정을 거쳤었는데, 이번 기회로 좀 더 자세히 알아볼 수 있어서, 유익한 시간이었다고 볼 수 있겠다.
728x90
반응형