본 포스팅은 인프런 최주호님의 '스프링부트 시큐리티 & JWT 강의'를 토대로 작성하였습니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0/dashboard
JWT에대해 알아보기 전에
- Http는 비연결성, 무상태라는 특징을 가지고 있음
> 사용자의 인증정보를 유지하기 위해서 SESSIONID와 같은 값을 헤더에 함께 담아서 서버에 전송
이 SESSIONID는 최초 요청시에 발급되며
1. 서버에서 세션을 강제로 지울때
2. 클라이언트가 브라우저를 종료할 때
3. 특정시간이 종료되었을때(보통 30분)
- Session으로 사용자 관리시 문제점
사용자가 많아서 여러개의 인스턴스로 구성 하여 로드밸런싱이 되는 경우
첫번째 요청과 두번째 요청이 같은 인스턴스가 응답을 받는다는 보장이 없음.
쉽게말해, 1번 instance는 사용자 인증정보를 가지고 있지만 2번 instance는 사용자 인증정보를 가지고 있지 않으므로
사용자의 로그인 여부를 파악할 수 없음
CIA
- 기밀성(Confidentiality), 무결성(Integrity), 가용성(Availability)
Confidentiality 기밀성
특정 정보에 대해서 허가된 사용자만 확인이 가능해야 한다.
A서버가 B서버로 보낼때 악의적인 사용자가 해당 데이터를 가로채서
전송되는 데이터를 확인할 수 있는 경우에 기밀성이 깨졌다고 표현한다.
Integrity 무결성
특정 정보에 대해서 허가된 사용자만 수정이나 삭제가 가능해야 한다.
A서버가 보내는 요청을 가로채서 데이터를 위변조 한 뒤
B서버로 변조된 데이터를 전송할 수 있는 경우에 무결성이 깨졌다고 표현한다.
Availability 가용성
사용자는 허가된 정보에 대해서 필요시 항상 접근이 가능해야 한다.
위와같은 과정을 통해서 데이터를 탈취당하거나, 제대로된 데이터에 접근 및 사용이 불가능 한 경우
가용성이 꺠졌다고 표현한다.
CIA를 지키기기 위한 방법과 문제점
- 1. 데이터를 암호화 한다.
암호화를 통해서 악의적인 사용자가 데이터에 접근하더라도 데이터의 내용을 확인할 수 없으므로, 기밀성이 지켜짐.
그러나, 데이터를 확인하기 위해선 위해서 데이터를 받는 서버도 복호화 Key가 있어야하며 이를 전달할 때 Key가 탈취될 가능성이 존재
이를 강의에선 쉽게 열쇠전달의 문제 라고 표현.- 2. 데이터의 수신자를 파악한다.
암호화를 통해서 데이터를 악의적인 사용자가 열어볼 순 없을지라도,
해당 데이터를 낚아채서 지운 뒤, 새로운 데이터를 보내려는 서버에 전달하는 경우
응답을 받는 서버는 해당 데이터가 유효한 데이터인지 확인하기가 어려움.
이를 강의에선 쉽게 너 누구야? 문제 라고 표현
RSA
- 현재 SSL/TLS에 가장 많이 사용되는 공개키 암호화 알고리즘.
- 공개키와 개인키가 한 쌍을 이루며, 공개키로 암호화한 내용은 개인키로만, 개인키로 암호화한 내용은 공개키로만 해독 가능
1. 열쇠전달의 문제
서버A가 서버B로 데이터를 전송하는 상황에서
데이터를 서버B의 공개키로 암호화
이렇게 암호화된 데이터는 서버B의 개인키로만 복호화가 가능!
암호화한 데이터를 풀기위한 복호화키를 전달하지 않으므로, 열쇠전달의 문제를 해결
2. 너 누구야? 인증문제
서버A가 서버B로 데이터를 전송하는 상황에서
데이터를 서버A의 개인키로 암호화
이는 데이터를 암호화 하는것에 목적이 있는것이 아님!
서버B는 서버A의 공개키로 데이터를 복호화 수행.
복호화가 정상적으로 진행된다면 데이터는 A의 개인키로 암호화 되어있다는 의미
이를 통해 너 누구야? 문제를 해결
개인키로 암호화 하였다는것은 전자서명을 의미
공개키로 암호화 하였다는것은 암호화를 의미
JWT(JSON Web Token)
- 당사자간의 정보를 JSON 객체로 안전하게 저송하기 위한 개방형 표준(RFC 7519)
- RSA 혹은 ECDSA를 사용하는 공개/ 개인키 쌍을 사용하여 서명 할 수 있음
- 정보의 암호화보다는 해당 서명(누가 전송했는지)에 중점을 두고있음
JWT의 구조
1. 헤더
일반적으로 토큰 유형과 사용중인 서명 알고리즘의 두 부분으로 구성
{
"alg" : "HS256",
"typ" : "JWT"
} 2. 페이로드
클레임 이라고 표현하는 key,value 형태의 정보로 담는부분
{
"name" : "HANA",
"useYN" : "Y"
"id" : "12"
} 3. 서명
인코딩된 헤더, 페이로드를 이용해서 지정된 알고리즘으로 서명
발신자의 개인키로 암호화하고, 발신자의 공개키로 복호화를 통해
메세지가 발신자로부터, 변경되지 않았음을 확인하는데 사용.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)JWT 기본흐름
Header와 PayLoad를 Base64로 암호화 한 뒤,
스프링에서 비밀번호를 저장하는 방법과 마찬가지로
복호화 불가능하게 인증을 만들어서
받은 Header와 Payload를 이용하여 재 암호화 한 값이
인증정보와 동일한지를 파악하는 흐름이다.
Base64는 복호화가 가능한 암호화 방식으로
JWT의 핵심목표는 정보의 암호화가 아닌 서명부를 활용한 인증정보 확인에 있다.
세션의 단점을 해결
서버의 스토리지에서 사용자의 정보를 가지고 확인하는것이 아닌
서버의 비밀키값만 알고있다면, 해당 JWT토큰을 검증하는 것으로 사용자 인증문제를
해결할 수 있다.
