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 로 인증 및 권한 허가를 받는 프로세스는 아래와 같다.
- 사용자 → id, pw 입력 (로그인 요청) → 서버
- 서버 → 비밀키로 인증 정보 담긴 json 객체 암호화하여 JWT 토큰 생성 및 발급 / 응답 헤더에 담음 → 클라이언트
- 클라이언트 → 로컬에 JWT 저장
- 추후 API 호출 시: 클라이언트 → 요청 헤더에 JWT 담아서 전송 → 서버
- 서버 API 응답 시: 서버 → 헤더에 JWT 확인 → 인증 되면 응답 → 클라이언트
- 4번 5번 프로세스에서 알 수 있는 건, 매번 통신 때마다 클라이언트는 자신을 인증해야하고, 서버는 검증을 해야한다.
- 즉 매번 인증이 필요하다는 것.
- 이는 HTTP 의 특성에 의한 것이다.
- Connectionless
- 한 번 통신 일어나면 바로 연결이 끊어짐
- Stateless
- 상태를 기억하지 않음
- 그래서 바로 직전의 동일한 클라이언트와 서버가 성공적으로 요청 - 응답을 했을 지라도, 해당 정보를 기억하지 않기 때문에, 새로운 요청 - 응답에 대해서는 또 새로 인증 과정을 거쳐야한다.
- Connectionless
2) JWT 구조
- Header
- Payload
- Signature
- Header 에서는 아래와 같은 정보를 담고 있다.
- alg
- 암호화 알고리즘 종류
- typ
- 토큰 타입
- alg
- Payload 은 사용자 정보를 담고 있고, 아래와 같은 구성이다.
- sub (subject)
- 토큰 제목
- aud (audience)
- 토큰 대상자
- iat (issued at)
- 토큰 발급일시
- exp (expired)
- 토큰 만료일시
- sub (subject)
- 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
반응형
'개발 공부' 카테고리의 다른 글
99클럽 30일차 TIL: Basic 인증 (1) | 2024.05.03 |
---|---|
99클럽 29일차 TIL: OAuth (0) | 2024.05.02 |
99클럽 27일차 TIL: 아키텍처 패턴 - SOA (0) | 2024.04.30 |
99클럽 26일차 TIL: 아키텍처 패턴 - 모노레포 (0) | 2024.04.29 |
99클럽 25일차 TIL: 아키텍처 패턴 - MSA (2) | 2024.04.28 |