728x90
JWT(JSON Web Token)
- JWT를 생성하기 위해서는 Header, Payload, Verify Signature 객체를 필요로함
Header
- key - value 형태로 구성됨
{
'alg': 'HS256',
'typ': 'JWT'
}
Payload
- key - value 형태로 구성됨
- 클레임 종류: Registered, Public, Private
- 일반적으로 만료 일시, 발급 일시, 발급자, 권한 정보 등을 포함
- 토큰에 여러개의 claim을 넣을 수 있음
- 민감한 정보를 넣으면 안 됨!!(암호화 안 됨!)
{
'sub': '1234567890',
'name': 'John Doe',
'admin': true,
'iat': 1516239022
}
(Verify)Signature
- Base64 방식으로 인코딩한 Header, Payload, Secret key를 더한 후 서명됨
- Secret Key(서버의 개인키)를 포함하여 암호화함
- 토큰의 유효성을 검증하기 위한 문자열로 구성
HMACSHA256 {
base64UrlEncode(header) + '.' +
base64UrlEncode(payload),
your-256-bit-secret
}
완성된 토큰
- Header, Payload는 인코딩될 뿐, 따로 암호화되지 않는다!!
장점
- 간편하고 추가 저장소가 필요 없음
- 확장성이 뛰어남. ⇒ 토큰 기반인 다른 인증 시스템에 접근 가능
단점
- Access Token(JWT)은 한 번 발급되면 유효기간이 완료될 때까지 계속 사용 가능하고, 중간에 삭제가 불가능하기 때문에 해커가 탈취한다면 대처 방법이 없음 ⇒ 해결책:
Refresh Token - Payload 정보가 디코딩될 수 있기 때문에 중요한 정보를 보관할 수 없음
- JWT 길이가 길기 때문에, 인증 요청이 많아질 경우 서버의 자원 낭비가 발생함
Access Token + Refresh Token 이용한 인증
- 토큰의 유효기간을 짧게 함 → 로그인을 자주 해야해서 번거로움
- 토큰의 유효기간을 길게 함 → 보안이 취약해짐
Refresh Token
- 사실 Access Token을 탈취 당했을 경우에 대한 최소한의 대비책임(해결책보단..)
- 인증 정보를 담고 있지 않고, 오로지 Access Token 재발급 용도로만 사용함
- Access Token보다 긴 유효기간을 가지고, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됨
- 즉, Refresh Token을 통해 다시 Access Token을 발급받아 사용함
- ex) Access Token 유효 기간 = 1h, Refresh Token 유효 기간 = 2 week
- 2주 동안 1시간마다 Access Token을 새롭게 발급받을 수 있음
인증 방법
- 사용자 로그인
- 서버는 회원 DB에서 값을 비교
3, 4. 로그인 완료시 Access Token, Refresh Token 발급하여 HTTP 응답 헤더에 실어 보냄
- 이때, DB에 Refresh Token 저장
- Refresh Token은 저장 후, Access Token을 HTTP 요청 헤더에 실어 요청을 보냄
- Access Token과 Refresh Token은 Session Storage에 저장
6, 7. Access Token을 검증해 맞는 데이터를 보냄
<Access Token 만료>
- 사용자가 만료된 Access Token을 HTTP 요청 헤더에 실어 보냄
10, 11. 서버는 Aceess Token이 만료됨을 확인하고, 권한 없음을 신호로 보냄
- 사용자는 Refresh Token과 Access Token을 HTTP 요청 헤더에 실어 보냄(Access Token 발급 요청)
- 서버가 Access Token이 조작되지 않았는지 확인 후, HTTP 요청 헤더의 Refresh Token과 사용자의 DB에 저장된 Refresh Token을 비교함.
- Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해주고, 새로운 Access Token을 HTTP 응답 헤더에 실어 다시 API 요청을 진행함
장점
- Access Token 유효기간이 짧아, Access Token만을 사용한 인증보다 안전
단점
- 구현이 복잡
- Access Token이 만료될 때마다 새롭게 발급하는 과정에서 서버의 자원 낭비 발생
728x90