JWT(JSON Web Token)
Json객체를 기반으로 한 사용자 인증 및 정보 전달을 위한 자체 포함형 토큰
🔍 자체 포함형이란?
JWT가 모든 필요한 정보를 자체적으로 담고 있다는 의미
이 구조는 JWT가 독립적으로 동작할 수 있도록 해주며, 서버에서 별도의 추가 데이터베이스 조회 없이도 인증이나 사용자의 권한을 확인할 수 있게 한다.
JWT의 구조
1. 헤더
주로 토큰의 유형(typ)과 사용된 서명 알고리즘(alg)을 정의
{
"alg": "HS256",
"typ": "JWT"
}2. 페이로드
사용자 정보의 한 조각인 클레임(claim)이 들어있다.
(토큰 사용자에 관한 정보나 추가 메타데이터를 담을 수 있다)
{
"email": "coderduck@gmail.com",
"username": "coderduck",
"iat": 1609239023, // 토큰 발행시간
"exp": 1609242623 // 토큰 만료시간
}3. 서명
토큰이 변조되지 않았음을 보장하는 암호화된 서명
헤더와 페이로드를 합친 뒤, 지정된 알고리즘으로 해시하고, 비밀키를 사용하여 서명한 결과
JWT의 동작방식
1. 토큰 발급
- 사용자 로그인
- 서버에서 인증정보(아이디, 비밀번호)를 검증하여 사용자 확인
- 서버가 비밀키를 사용해 json 객체를 암호화한
JWT를 생성하여 반환
🙂 주로 JWT 토큰 2개를 발급한다(Acses Token과 Refresh Token)
2. 토큰 전송
클라이언트는
JWT를 로컬에 저장해놓고, 보호된 리소스 접근할떄마다 서버에 전송
🙂 클라이언트 JWT 저장위치
쿠키, 스토리지, 함수 스코프 내에서만 동작하는 로컬변수
3. 토큰 검증
서버가 클라이언트로부터
JWT를 받으면 유효한 토큰인지 검증
🙂 검증방법
1️⃣ JWT 형식 검증 (Header.Payload.Signature 구조 확인)
2️⃣ JWT 디코딩 (Base64로 디코딩하여 Header, Payload 추출)
3️⃣ 서명 검증 (토큰이 변조되지 않았는지 확인)
4️⃣ 토큰 만료 여부 확인
5️⃣ 발급자, 대상확인
4. 권한에 따른 처리
서버는
JWT Payload에 포함된 사용자 정보, 권한을 통해서 인가 처리
Access Token, Refresh Token
JWT는 유저의 신원이나 권한을 결정하는 정보를 담고 있는 데이터 조각이다.
JWT 인증방식은 비밀키로 암호화를 하기 때문에 클라이언트와 서버는 안전하게 통신하다.
하지만 JWT는 탈취당할 경우 보안에 취약하다.
JWT를 탈취한 사람은 마치 신뢰할만한 사람인 것처럼 인증을 통과할 수 있기 때문이다.
따라서 토큰의 유효 기간을 두어야한다.
그런데 유효기간을 짧게 두면, 사용자가 로그인을 자주 해야하므로 사용자 경험적으로 좋지 않고, 유효기간을 길게 두면, 보안상 탈취 위험에서 벗어날 수 없다.
이를 위해, Acses Token과 Refresh Token이 탄생했다.
Access Token
-
클라이언트가
API 요청을 보낼 때 매번사용 -
유효기간이 짧다.
Refresh Token
-
Access Token이 만료되어 갱신할 때만 사용 -
유효기간이 길다.
-
Refresh Token은 유출되면Access Token을 무한정 발급받을 수 있음 -
반드시 안전한 저장 방법 사용 =>
HTTP-Only Secure Cookie에 저장 권장 -
보안 강화를 위해 일정 기간마다
Refresh Token도 갱신해야 함
1. 사용자가 ID , PW를 통해 로그인
2. 서버에서 DB에서 값을 비교
3~4. 로그인이 완료되면 Access Token, Refresh Token 발급.
(이때 DB에도 Refresh Token 저장)
5. 클라이언트는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보낸다.
6~7. Access Token을 검증하여 이에 맞는 데이터를 보낸다.
8. 시간이 지나 Access Token이 만료됐다.
9. 클라이언트는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다.
10~11. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.
12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.
13. 서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 DB에 저장되어 있던 Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해준다.
14. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청 응답을 진행한다.
참고자료
