Cookie(쿠키)/Session(세션)/Token(토큰)/JWT 개념 및 특징, 인증 방식, 차이점

쿠키(Cookie) ❔

서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각.

브라우저에서 서버에 요청을 보내면 서버는 브라우저에 응답을 보내게 되는 구조에서 서버에서 온 응답에는 브라우저에 저장하고자 하는 쿠키가 존재.

웹 사이트를 이용할 때 쓰는 프로토콜인 HTTP는 무상태성(stateless)을 가지고 있기 때문에 클라이언트 요청이 끝나고 나면 서버는 해당 클라이언트가 누군지 모르기 때문에 요청할 때마다 누군지 알려줘야 하는 상황이 발생!

(+ 서버로 가는 모든 요청이 이전 요청들과 독립적으로 다뤄지며 각 요청끼리는 연결점이 없다.)

 

즉, HTTP 쿠키는 상태가 있는 세션을 만들도록 해주며 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키 추가

 

+ 쿠키는 도메인에 따라 제한
+ 쿠키는 유효기간이 있음 (설정 가능)

+ 쿠키는 용량 제한이 있어 많은 정보 담기 불가능

 

 

✔ 쿠키 사용 목적

1. 세션관리 : 서버에 저장해야할 정보
2. 개인화 : 사용자의 설정
3. 트래킹 : 웹 사이트 내 행동 기록 관리

 

 

---

 

세션(Session) ❔

사용자가 웹사이트에 로그인했을 때 사용자에 대한 정보를 일정 기간 동안에 서버에 기록하고 보관함으로써 사용자를 관리하기 위한 목적으로 사용되는 서버의 저장 공간.

Session은 일정 기간이 지나면 사리지게 되고 이를 통해서 보안 유지.

사용자는 로그인 할 때마다 쿠키에 세션 아이디를 담아서 서버에 전송하고 서버는 Session ID와 일치하는 유저의 정보를 데이터베이스에서 조회.
즉, 요청이 있을 때마다 디비를 조회하게 되므로 요청이 많아지면 많아질 수록 디비 리소스가 더 필요한 상황 발생.

이와 같이 서버 부담이 매우 커지는 상황이 발생하게 되는데 이에 대한 해결 책으로 토큰 인증 방식 등장 ✨

 

 

✔ 세션 기반 처리 인증 과정

1. 사용자가 아이디/비밀번호(인증 정보)를 사용하여 서버에 로그인 요청

2. 서버에서 받은 인증 정보와 데이터 베이스에 저장된 사용자 정보를 확인

3. 인증 성공 시엔 서버에 인증 정보를 서버 메모리에 저장

4. 쿠키에 세션 ID를 넣어 사용자에게 전달 후 저장

5. 서버로 리소스를 요청할 시, 쿠키에 세션 ID 와 함께 서버에 요청

6. 서버는 세션 ID를 가지고 데이터 베이스 조회 실행

7. 조회 후 해당 요청 건에 맞춰 사용자에게 결과 전달

 

 

---

 

토큰(Token) ❔

= 동전, 웹 상에서는 사용 가능한 동전에 특정 권한을 주는 것.

서버에 저장하는 세션과 달리 토큰은 클라이언트에 인증 정보를 저장.

 

 

✔ 토큰 기반 처리 인증 과정

1. 사용자가 아이디/비밀번호(인증 정보)를 사용하여 서버에 로그인 요청

2. 서버에서 받은 인증 정보가 유효한지 데이터 베이스 조회하여 확인

3. 해당 요청이 유효하면 토큰을 생성하고 토큰 정보를 Response 헤더에 포함시켜 반환

이로인해 사용자는 로컬 스토리지에 토큰 저장

4. 사용자는 제한된 end points에 접근할 때 모든 Request Header에 토큰 정보를 포함

5. 만약 Request Header에 포함된 토큰이 유효하면 서버는 사용자가 특정 end point에 접근하는 것을 허용, JSON 또는 XML 포맷으로 응답

 

✔  토큰 기반 인증 방법 2가지

1. 일반 토큰

의미가 없는 문자열로 구성

• 단순한 문자열이기 때문에 정보를 담거나 할 수 없다.
• 발급된 토큰에 대해 만료를 시킬 수단이 없다.
• 발급된 토큰을 검사하거나 처리 할 때마다 DB에 접근하여 검사할 경우 부담이 생긴다.

2. 클레임 토큰 
사용자 정보나 데이터 속성등을 의미

대표적인 클레임 토큰, JWT 

 

 

---

 

JWT(Json Web Token) ❔

= 유저를 식별하고 인증하기 위한 토큰 기반 인증.

RESTful과 같이 Stateless인 환경에서 사용자 데이터를 주고 받을 수 있는 특징을 지님.

 

 

✔  구조

aaaaa.bbbbbb.ccccc

[header].[payload].[signature]

 

.을 기준으로 3부분으로 나뉘어 표현

 

 

1. Header

키(kid), 사용할 타입(typ), 서명 암호화 알고리즘(alg)의 정보가 담김.

• kid : 서명 시 사용하는 키(Public/Private Key)를 식별하는 값
• typ : 토큰 유형
• alg : 서명 암호화 알고리즘 HS256(HMAC SHA-256), HS512, RS256(RSASSA SHA-256), ES256(ECDSA P-256 curve SHA-256)

2. Payload

토큰에서 사용할 정보 조각이 담김( claim )

클레임은 key, value의 형태이며 등록된 클레임, 공개 클레임, 비공개 클래임으로 나뉨.

• iss : 토큰 발급자(issuer) – Public Claims
• sub : 토큰 제목(subject) – Public Claims
• iat : 토큰 발급 시간(issued at) – Public Claims
• exp : 토큰 만료 시간(expiration) – Public Claims
• roles : 권한 – Private Cliams

3. Signature

헤더에서 정의한 알고리즘 방식 활용( alg )

Header + Payload 와 서버가 갖고 있는 유일한 key 값을 합친 것을 헤더에서 정의한 알고리즘으로 암호화 진행.

토큰의 위변조 여부를 확인하는데 사용.

( Header 와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작할 수 있지만,

Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없습니다. )

하지만 외부의 공격자가 액세스 토큰이 만료되기 전에 토큰 탈취를 시도했다면 해당 토큰에 대한 권한 접근이 가능해 보안에 취약해질 수 있다.

JWT는 발급 후 삭제 처리가 불가능하여 유효 시간을 설정하여 보안상 문제점에 대응.

 

 

* jwt 토큰 구조 확인해 볼 수 있는 사이트

JWT.IO

 

 

 

(JWT 인증 강화 방식에 대한 포스팅은 따로 하도록 하겠습니다! 😃)

 

 

 

 

 

 

 

 

 

 

 

---

[참고]

https://developer.mozilla.org/ko/docs/Web/HTTP/

https://velog.io/@ukk/%ED%86%A0%ED%81%B0%EC%9D%B4%EB%9E%80

https://behonestar.tistory.com/37

https://velog.io/@hahan/%ED%86%A0%ED%81%B0%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%EC%A2%85%EB%A5%98

https://blog.bizspring.co.kr/%ED%85%8C%ED%81%AC/jwt-json-web-token-%EA%B5%AC%EC%A1%B0-%EC%82%AC%EC%9A%A9/