세션 기반 자격 증명 방식 VS 토큰 기반 자격 증명 방식
세션 기반 자격 증명 방식
서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식
특징
- 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.
- 생성된 사용자 세션의 고유 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
- 서버 측에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리하다.
- 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.
- 세션 데이터가 많아질수록 서버의 부담이 가중된다.
- SSR(Server Side Rendering) 방식의 애플리케이션에 적합하다.
토큰 기반 자격 증명 방식
특징
- 토큰에 포함된 인증이 된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.
- 생성된 토큰을 헤더에 포함시켜 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용.
- 토큰 내에 인증된 사용자 정보 등을 포함하고 있으므로 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용한다.
- 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 조금 더 불리하다.
- 인증된 사용자 request의 상태를 유지할 필요가 없기 떄문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다.
- 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이다. 고로 민감한 정보는 토큰에 포함시키지 말아야 한다.
- 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.
- CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식이다.
JWT(JSON Web Token)
- 인증이 된 사용자의 자격을 추가적으로 증명하는 토큰 방식 중 가장 범용적으로 사용된다.
- JWT는 데이터를 안전하고 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식
- JSON 포맷의 토큰 정보를 인코딩 후, 인코딩 된 토큰 정보를 Secret Key로 서명(Sign)한 메시지를 Web Token으로써 인증 과정에 사용한다.
JWT의 종류
보통 두 가지
1. 액세스 토큰(Access Token)
2. 리프레시 토큰(Refresh Token)
Access Token
보호된 정보들(ex.사용자의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용.
클라이언트가 처음 인증을 받게 될 때(로그인 시), Access Token과 Refresh Token 두 가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 Access Token이다.
- Access Token을 악의적인 사용자가 얻어낼 수도 있는 상황이 있기 때문에, 유효기간을 짧게 주어서 탈취되더라도 오래 사용 못하도록 해야한다.
Access Token의 유효기간이 만료되면 Refresh Token을 사용해서 새로운 Access Token을 발급받는다.
- 이 때 다시 로그인 인증을 할 필요는 없다.
Refresh Token
Refresh Token을 탈취당하면, Refresh Token을 이용하여 Access Token을 다시 발급받을 수 있으므로 사용자에게 큰 피해를 입힐 수 있다.
그렇기 때문에 사용자의 편의보다 사용자의 정보를 더욱 중요시 하는 웹 애플리케이션에는 Refresh Token을 사용하지 않는 곳이 많다.
JWT 구조
aaaaaa.bbbbbb.cccccc같이 있다. .으로 세 부분이 존재하는데
aaaaaa에 해당하는 부분이 Header,
bbbbbb에 해당하는 부분이 Payload,
cccccc에 해당하는 부분이 Signature이다.
1. Header
이 토큰이 어떤 종류의 토큰인지, 어떤 알고리즘으로 Sign할지 정의하는 부분이다.
JSON 포맷 형태로 정의한다.
{
"alg":"HS256",
"typ":"JWT"
}위의 JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성된다.
2. Payload
서버에서 활용할 수 있는 사용자의 정보가 담겨있다.
어떤 정보에 접근이 가능한지에 대한 권한을 담을 수도 있고, 사용자의 이름 등 필요한 데이터를 담을 수 있다.
Payload는 Signature을 통해 유효성이 검증될 정보긴 하나, 민감한 정보는 담지 않는 것이 좋다.
{
"sub" : "someInformation",
"name" : "phillip",
"iat" : 15162391
}마찬가지로, 위 JSON의 객체를 base64로 인코딩하면 두번째 부분이 완성된다.
3. Signature
base64로 첫 번째 부분과 두 번째 부분이 완성되었으면,
Signature에서는 원하는 비밀 키(Secret Key)와 Header에서 지정한 알고리즘을 사용해서 Header와 Payload에 대해서 단방향 암호화를 수행한다.
- 이 암호화 된 메세지는 토큰의 위변조 유무를 검증하는데 사용된다.
ex) HMAC SHA256 알고리즘을 사용한다면 Signature는 아래와 같은 방식으로 생성된다.
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);JWT 사용 예시
JWT는 권한 부여에 매우 유용하다.
예를 들어 IC(아이씨:아저씨)라는 앱이 Gmail과 연동되어 이메일을 읽어와야 한다 생각했을 때,
이 경우
1. Gmail 인증서버에 로그인 정보(아이디, 비밀번호)를 제공한다.
2. 인증에 성공할 경우, JWT를 발급 받는다.
3. IC 앱은 JWT를 사용해 해당 사용자의 이메일을 읽거나 사용할 수 있다.
토큰기반 인증 절차
- 클라이언트가 서버에 아이디/비밀번호를 담아서 로그인 요청을 보낸다.
- 아이디/비밀번호가 일치하는지 확인하고, 클라이언트에게 보낼 암호화 된 토큰을 생성한다.
- Access Token과 Refresh Token을 모두 생성한다.
- 토큰에 담길 정보(Payload)는 사용자를 식별할 정보, 사용자의 권한 정보 등이 될 수 있다.
- Refresh Token을 이용해서 새로운 Access Token을 생성할 것이므로 두 종류의 토큰이 굳이 같은 정보를 담을 필요는 없다.
- 토큰을 클라이언트로 전송하면, 클라이언트는 토큰을 저장한다.
- 저장하는 위치는 Local Storage, Session Storage, Cookie 등이 될 수 있다.
- 클라이언트가 HTTP Header(Authorization Header) 또는 쿠키에 토큰을 담아 request를 전송한다.
- Bearer authentication을 이용함.
- 서버는 토큰을 검증하여 서버에서 발급해준 토큰이 맞다고 판단이 될 경우, 클라이언트의 요청을 처리한 후 응답을 보내준다.
JWT의 장점과 단점
JWT를 통한 인증의 장점
- 상태를 유지하지 않고(Stateless), 확장에 용이한(Scalable) 애플리케이션을 구현하기 용이하다.
- 서버는 클라이언트에 대한 정보를 저장할 필요 없다.(토큰이 정상적으로 검증되는지만 판단한다.)
- 클라이언트는 request를 전송할 때마다 토큰을 헤더에 포함시키면 된다.
- 여러대의 서버를 이용한 서비스라면 하나의 토큰으로 여러 서버에서 인증이 가능하기 때문에 JWT를 사용하는 것이 효과적이다.
- 단, 세션 방식이라면 모든 서버가 해당 사용자의 세션 정보를 공유하고 있어야 한다.
- 여러대의 서버를 이용한 서비스라면 하나의 토큰으로 여러 서버에서 인증이 가능하기 때문에 JWT를 사용하는 것이 효과적이다.
- 클라이언트가 request를 전송할 때마다 자격 증명 정보를 전송할 필요가 없다.
- HTTP Basic 같은 인증 방식은 request를 전송할 때마다 자격 증명 정보를 포함해야하지만 JWT의 경우 토큰이 만료되기 전까지는 한번의 인증만 수행하면된다.
- 인증을 담당하는 시스템을 다른 플랫폼으로 분리하는 것이 용이하다.
- 사용자의 자격 증명 정보를 직접 관리하지 않고, Github, Google 등의 다른 플랫폼의 자격 증명 정보로 인증하는 것이 가능하다.
- 토큰 생성용 서버를 만들거나, 다른 회사에서 토큰 관련 작업을 맡기는 것 등 다양한 활용이 가능하다.
- 권한 부여에 용이하다.
- 토큰의 Payload(내용물) 안에 해당 사용자의 권한 정보를 포함하는 것이 용이하다.
JWT를 통한 인증의 단점
-
Payload는 base64로 인코딩 되기 때문에 토큰을 탈취하여 Payload를 디코딩하면 토큰 생성시 저장한 데이터를 확인할 수 있다. 따라서 Payload에는 민감한 정보를 포함하지 않아야 한다.
-
토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있다.
- 토큰에 저장하는 정보의 양이 많아질수록 토큰의 길이는 길어진다. 따라서 request를 전송할 때마다 길이가 긴 토큰을 함께 전송하면 네트워크에 부하를 줄 수 있다.
- 토큰은 자동으로 삭제되지 않는다.
- 한 번 생성된 토큰은 자동으로 삭제되지 않기 때문에 토큰 만료 시간을 반드시 추가해야 한다.
- 또한 토큰이 탈취된 경우 토큰의 기한이 만료될 때까지 토큰 탈취자가 해당 토큰을 정상적으로 이용할 수 있으므로 만료 시간을 너무 길게 설정하지 않아야 한다.
커밋 ㅇ