세션/쿠키 , JWT

항상 공부하면서 서버 인증에 관하여 모르는 부분이 있어도 쉽게쉽게 넘어가서 개념 정리겸 확실히 알아가기 위해서 정리를 해둔다.

왜 인증을 하는가?

인증은 프론트엔드 관점에서 사용자의 로그인,회원가입과 같이 사용자의 도입 부분을 가리키곤 한다.
반면 서버사이드 관점에서 볼 때 모든 API요청에 대해 사용자를 확인하는 작업이다.

HTTP 요청에 대해서

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

서버에 요청을 보내는 작업은 HTTP 메세지를 보내는 것이다. 일반적으로 헤더와 바디 두가지로 구성되며, 공백은 헤더와 바디를 구분짓는 역할. 여기서 헤더에는 기본적으로 요청에 대한 정보들이 들어갑니다. 바디에는 서버로 보내야 할 데이터가 들어가게 된다. 보통 모바일/웹 서비스의 인증은 HTTP메세지의 헤더에 인증 수단을 넣어 요청을 보내게 된다.

인증 방식

1. 계졍 정보를 요청 헤더에 넣는 방식

가장 보안이 낮은 방식은 계정정보를 요청에 담아 보내는 방식이다. HTTP요청에 인증할 수단에 비밀번호를 넣는다.
최악의 인증방식으로 사용자의 개인 정보를 계속해서 보내는 것은 보안에 안좋다.

2. Session/Cookie 방식

1번과 같이 계정정보를 요청 헤더에 넣는 방식은 너무 보안이 취약하다라는 단점을 때문에 나온 인증 방식이 Session/Cookie이다.

순서를 한번 보자.

1. 사용자가 로그인을 한다.
2. 서버에서는 계정정보를 읽어 사용자를 확인 후 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 다음 이와 연결되는 세션 ID를 발행한다.
3. 사용자는 서버에서 해당 세션ID를 발급 받아 쿠키에 저장한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보낸다.
4. 서버에서는 쿠키를 받아 세션 저장소에서 검증한 후 대응되는 정보를 가져온다.
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.

장점

• 세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거친다. 여기서 쿠키는 세션 저장소에 담긴 유저정보를 얻기위한 키(key) 라고 보자. 따라서 쿠키가 담긴 HTTP요청이 도중에 노출되더라도 쿠키 자체는 유의미한 값을 가지고 있지 않다.

단점

• 만일 다른 사용자가 현재 사용자의 HTTP요청을 가로챘다면 그 안에 들어있는 쿠키도 훔칠 수 있다. 그리고 다른 사용자는 그 훔친 쿠키를 이용해 HTTP요청을 보내면 서버의 세션저장소에서는 원래 사용자로 오인해 정보를 잘못 뿌려 줄 것이다.

3. 토큰 기반 인증 방식(JWT)

JSON Web Token의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다. 세션/쿠키와 유사하게 사용자는 Access Token을 HTTP헤더에 실어 서버에 보내게 된다.

토큰을 만들기 위해서는 크게 3가지로 나뉜다. Header,payload,signature

1. Header : 헤더는 두가지의 정보를 지니고 있다. typ,alg typ는 토큰의 타입을 지정한다. 바로 JWT alg는 해싱 알고리즘을 지정한다 해싱알고리즘으로는 보통 HMAC SHA256,RSA가 사용되며 이 알고리즘은, 토큰을 검증 할 때 사용되는 시그니처 부분에서 사용된다.

{
"typ" : "JWT"
"alg" : "HS256"
}

2. Payload : 페이로드 부분에는 토큰을 담을 정보가 들어있다. 여기에 담는 정보의 한 "조각"을 클레임(claim)이라고 부르고 name/value의 한 쌍으로 이뤄져있다. 토큰에는 여러개의 클레임들을 넣을 수 있다.
   클레임의 종류는 세분류로 나뉘어져있다. 등록된 클레임,공개클레임,비공개클레임

{
  "iss": "naver.com",
    "exp": "1485270000000",
    "https://naver.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "hell"
}

3. signature : JSON Web Token의 마지막 부분은 바로 서명이다. 이 서명은 헤더의 인코딩값과 정보의 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성

• 최종적인 결과로 Encoded Header + '.' + 'Encoded payload' + '.' + Sifnature

그렇다면 JWT가 어떻게 인증에 사용되는지 알아보자

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

• 장점

1. 세션/쿠키는 별도의 저장소 관리가 필요하지만 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다. 이것은 Stateless한 서버를 만들어 유지 보수하는데 유리하다.
2. 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다.

REF : https://tansfil.tistory.com/59?category=255594