[Auth] 쿠키, 세션 그리고 jwt

인증을 왜 하는가 ?

프론트엔드 관점 : 사용자의 로그인, 회원가입과 같이 사용자의 도입 부분

백엔드 관점 : 모든 api 요청에 대해 사용자를 확인하는 작업

 

HTTP 요청에 대해서

현재 가장 많이 쓰이는 통신 방식은 HTTP통신이다. HTTP 통신은 응답 후 연결을 끊기게 되며 과거에 대한 정보를 전혀 담지 않는다. 이 말은 지금 보낸 HTTP 요청은 과거에 내 정보를 담아 보낸 HTTP요청과는 전혀 관계가 없다. 따라서 각각의 HTTP요청에는 보내는 주체가 누구인지에 대한 정보가 필수적이다.

 

http 메시지

• 헤더 : 요청에 대한 정보들이 들어간다. 보통 이 헤더에 인증 수단을 넣어 요청을 보내 인증을 수행함.
• 바디 : 서버로 보내야 할 데이터가 들어간다.

인증방식

1. 계정 정보를 요청 헤더에 넣는 방식 : 보안이 너무 안좋음

2. Cookie / Session 방식

기본적으로 쿠키를 매개로 인증을 거친다. 따라서 이 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체는 유의미한 값을 가지고 있진 않다.

 

3. 토큰 기반 인증 방식 ( JWT _ JSON Web Token )

Session/Cookie 인증 방식과 비슷하나, 여기선 Cookie 가 아니라 Access Token 이 HTTP 헤더에 실려 서버에 보내진다.

 

토큰의 구조는 이렇게 생겼다.

{ "typ" : "JWT" "alg" : "HS256","kid": "Key ID" }

• Header
  • typ : 토큰의 타입 지정
  • alg : 해싱 알고리즘 지정
  • kid : 서명 시 사용하는 키(Public/Private Key)를 식별하는 값이다.

• Payload : 토큰을 담을 정보가 들어있다.
• signature : 헤더의 인코딩값과 정보의 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성한다.

 

 

1. 사용자가 로그인을 한다.
2. 서버에서 계정정보를 읽어 사용자를 확인 후 사용자의 고유한 ID값을 부여한 후, 기타정보와 함께 Payload에 넣는다.
3. JWT 토큰의 유효기간을 설정
4. 암호화할 시크릿 키를 이용해 액세스 토큰을 발급한다.
5. 사용자는 액세스 토큰을 받아 저장한 후 인증이 필요한 요청마다 토큰을 헤더에 실어 보낸다.
6. 서버에서는 해당 토큰의 시그니처를 시크릿 키로 복호화한 후, 조작 여부, 유효기간을 확인한다.
7. 검증이 완료되면 페이로드를 디코딩하여 사용자에 ID에 맞는 데이터를 가져온다.

 

 

참고

velog.io/@sooonding/%EC%84%B8%EC%85%98%EC%BF%A0%ED%82%A4-JWT

세션/쿠키 , JWT

meetup.toast.com/posts/239

JWT를 소개합니다. : NHN Cloud Meetup