세션과 JWT

세션과 JWT는 모두 인가에 관한 보안 기술이다. 그렇다면 인가란 무엇일까?

1. 인가란?

• 인가란 사용자에게 특정 리소스나 기능에 액세스 할 수 있는 권한을 부여하는 프로세스를 말한다.
• 대표적으로, 서버에서 특정 파일을 다운로드할 수 있는 권한을 부여하거나, 개별 사용자에게 관리자 권한으로 애플리케이션에 액세스 할 수 있는 권한을 부여하는 경우가 여기에 해당된다.

2. 세션

2.1 정의

• 세션은 일정 시간 동안 같은 사용자(웹 브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이다.
• 여기서 일정 시간이란 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점을 뜻한다.
• 정리하자면 방문자가 웹 애플리케이션에 접속해 있는 상태를 하나의 단위로 보고 세션이라고 명명한다.

2.2 동작 순서

1. 사용자가 웹사이트에서 로그인하면 사용자의 정보가 서버 메모리(혹은 DB)상에 저장된다. 이때, 세션을 식별하기 위한 세션 ID를 기준으로 정보를 저장한다.
2. 클라이언트는 쿠키에 세션 ID를 저장하고 있다.
3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 세션 ID를 쿠키에 담아 전송한다.
4. 서버는 클라이언트가 보낸 세션 ID와 서버에서 관리하고 있는 세션 ID를 비교하여 인가를 부여한다.

2.3 특징

• 클라이언트의 정보를 서버에서 저장하고 있어서 보안적인 측면에서 사용자 정보를 클라이언트 측에 저장하는 쿠키보다 우수하다.
• 예기치 않은 로그아웃으로부터 특정사용자의 이전 기록 복원이 가능하게 한다.
• 단점으로는 사용자가 많아질수록 서버의 자원을 소모하게 된다. 

3. JWT

3.1 정의

Json을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 웹 토큰이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained(필요한 모든 정보를 자체적으로 지니고 있어서 자신의 객체를 사용하는 것) 방식으로 정보를 안전하게 전달한다. 

Claim에 대한 정의는 아래에서 인용했다.

클레임(Claim)은 주체가 수행할 수 있는 작업보다는 주체가 무엇인지를 표현하는 이름과 값의 쌍입니다. 예를 들어서, 여러분이 지역 운전면허 발급기관에서 발급한 운전 면허증을 갖고 있다고 가정해 보겠습니다. 운전 면허증에는 생년월일이 기재되어 있을 것입니다. 이 경우, 클레임 이름은 DateOfBirth가 되고, 클레임 값은 8th June 1970 같은 생년월일, 그리고 발급자는 운전면허 발급기관이 됩니다. 
출처는 이곳

3.2 구조

'.'을 구분 문자로 헤더, 내용(payload), 서명 부분을 Base64 URL로 인코딩 되어 표현된다. 

3.2.1 헤더

헤더에는 JWT에서 사용할 타입과 서명을 해싱하기 위한 해시 알고리즘의 종류가 담겨 있다. 

 

{
    "alg": "HS256",  // 알고리즘 방식을 지정하며, 서명 및 토큰 검증에 사용
    "typ": "JWT"  // 토큰의 타입을 지정
 }

3.2.2 내용 (payload)

토큰에서 사용할 정보의 조각들인 Claim(Key-value 형식으로 이루어진 한 쌍의 정보) 이 담겨 있다.(실제 JWT를 통해서 알 수 있는 데이터) 즉, 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용을 담고 있다.

{
    "sub": "12345678",
    "name": "Lee",
}

페이로드는 정해진 데이터 타입은 없지만, 대표적으로 Registered claims, Public claims, Private claims 이렇게 세 가지로 나뉜다.

• Registed claims : 미리 정의된 클레임.
  
  • iss(issuer; 발행자),
  • exp(expireation time; 만료 시간),
  • sub(subject; 제목),
  • iat(issued At; 발행 시간),
  • jti(JWI ID)
• Public claims : 사용자가 정의할 수 있는 클레임 공개용 정보 전달을 위해 사용.
• Private claims : 해당하는 당사자들 간에 정보를 공유하기 위해 만들어진 사용자 지정 클레임. 외부에 공개돼도 상관없지만 해당 유저를 특정할 수 있는 정보들을 담는다

3.3.3 서명(signature)

시그니처에서 사용하는 알고리즘은 헤더에서 정의한 알고리즘 방식을 활용한다. 서명(Signature)은 위에서 만든 헤더(Header)와 페이로드(Payload)의 값을 각각 Base64로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 헤더(Header)에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 Base64로 인코딩하여 생성한다.

3.3.4 JWT 토큰 예시

출처는 이곳(https://mangkyu.tistory.com/56)

3.4 특징

3.4.1 장점

• Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요 없다.
• JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
• 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(StateLess)가 되어 서버 확장성이 우수해질 수 있다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. (쿠키와 차이)
• OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
• 모바일 애플리케이션 환경에서도 잘 동작한다. (모바일은 세션 사용 불가능)

3.4.2 단점

• 토큰이 만료되기 전에 노출되면 보안적으로 매우 취약하다.
• Claim이 많아질수록 JWT토큰이 길어진다. 길이가 길어질수록 네트워크 대역폭 낭비가 심해질 수 있다.
• PayLoad에 대한 정보는 암호화되지 않고, Base64 인코딩만 되기 때문에 중간에 패킷을 가로채거나 토큰을 취득하게 되면, 데이터를 확인할 수 있다. 이를 해결하기 위해 JWE(Json Web Encryption)을 통해 암호화하거나 중요 데이터를 PayLoad에 넣지 않도록 해야 한다.
• JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다.

3.5 JWT의 Access Token / Refresh Token 방식

이 JWT도 제 3자에게 토큰 탈취의 위험성이 있기 때문에, 그대로 사용하는 것이 아닌 Access Token, Refresh Token으로 이중으로 나누어 인증을 하는 방식을 현업에선 취한다.

Access Token과 Refresh Token은 둘 다 똑같은 JWT이다. 다만 토큰이 어디에 저장되고 관리되느냐에 따른 사용 차이일 뿐이다.

• Access Token : 클라이언트가 갖고 있는 실제로 유저의 정보가 담긴 토큰으로, 클라이언트에서 요청이 오면 서버에서 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행
• Refresh Token: 새로운 Access Token을 발급해주기 위해 사용하는 토큰으로 짧은 수명을 가지는 Access Token에게 새로운 토큰을 발급해주기 위해 사용. 해당 토큰은 보통 데이터베이스에 유저 정보와 같이 기록.

개념이 생소할 수 있지만 Access Token은 우리가 지금까지 설명한 JWT를 말하는 것이라고 보면 된다.

정리하자면, Access Token은 접근에 관여하는 토큰, Refresh Token은 재발급에 관여하는 토큰의 역할로 사용되는 JWT인 것이다.

 

---

 

참고 

1. https://www.okta.com/kr/identity-101/authentication-vs-authorization/

인증과 인가 (권한 부여) 비교 – 특징 및 차이점 | Okta Identity Korea

2. https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

[WEB] 📚 JWT 토큰 인증 이란? - 💯 이해하기 쉽게 정리

3. https://interconnection.tistory.com/74

쿠키와 세션 개념

4. https://velog.io/@gotaek/%EC%84%B8%EC%85%98Session%EA%B3%BC-JWT

세션(Session)과 JWT

5. https://12bme.tistory.com/130

[정보보안] REST JWT(JSON Web Token) 이란?

6. https://okayoon.tistory.com/entry/%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%9D%B8%EC%A6%9D-%ED%86%A0%ED%81%B0-JWTJson-Web-Token%EB%9E%80-%EB%AD%98%EA%B9%8C

사용자 인증? 토큰? JWT(Json Web Token)란 뭘까?

7. https://etloveguitar.tistory.com/101

[JWT] JWT란 무엇인가? (JSON Web Token) 쉽게 정리한 core개념들