서버인증(세션/쿠키, JWT)

인증은 모든 API 요청에 대해 사용자를 확인하는 작업이라고 생각하면 된다.
사용자 A, B가 있는데 서버에서는 누가 보낸 요청인지 정확히 알아야한다.

이때 쓰는 통신 방식이 HTTP 통신입니다.
HTTP 통신은 응답 후 연결이 끊기며 과거에 대한 정보를 담지 않는 stateless상태이다.

따라서 서버에 요청을 보내는 작업은 HTTP 메시지를 보내는 것이다. HTTP 메시지의 구조는

요청라인
헤더
공백
바디

이렇게 되어있다. 헤더와 바디를 나누는 기준이 공백이다.
바디에는 서버로 보낼 데이터가 저장되고, 헤더에는 기본적으로 요청에 대한 정보가 들어간다.
보통 웹 / 앱 서비스의 인증은 HTTP 메시지의 헤더에 인증수단을 넣어 요청을 보내게 된다.

인증방식은 3가지로 나눠져있다.
1. 계정 정보를 요청 헤더에 넣는 방식
2. Session/Cookie 방식
3. 토큰기반인증방식(ex(JWT))

1. 계정 정보를 요청헤더에 넣는 방식
   이 가장 보안이 낮은 방식입니다.
   HTTP요청에 비밀번호를 넣습니다.

<장점>

• 개인 개발해보기 좋다
• 테스트 해보기 좋다

<단점>

• 보안에 매우 취약하다
• 서버에서는 신호가 올때마다 Id, PW를 통해 유저가 맞는지 인증해야한다.

2. Session/Cookie 방식
   1번 방식이 매번 요청에 넣어서 보내기엔 보안에 취약하기에 나온 인증 방식이다.
   

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

세션 쿠키 방식의 인증은 기본적으로 세션 저장소를 필요로한다.
이 세션 저장소가 Redis!! (필자가 사용할 세션저장소로는 Redis임)
세션 저장소는 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션 ID값을 만든다.
그리고 HTTP 헤더에 실어서 사용자에 돌려보낸다
사용자는 쿠키로 보관하고있다가 인증이 필요한 요청에 쿠키(session id)를 넣어
보낸다. 웹 서버에서는 세션 저장소에서 쿠키(세션 ID)를 받고 저장되어있는 정보와 매칭 시켜 인증을 완료한다.

세션 vs 쿠키
세션은 서버에서 가지고있는 정보
쿠키는 사용자에게 발급된 세션을 열기 위한 열쇠(세션 ID)

<장점>

• 세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거친다.
  쿠키는 레디스에 담긴 유저 정보를 얻기위한 열쇠라고 생각하기
  쿠키가 담긴 HTTP 요청이 도중에 도출되더라도 쿠키 자체는 열쇠기때문에 민감한 정보가 아님

• 랜덤으로 고유의 ID값을 발금해줌, 그렇게 되면 서버에서는 쿠키값을 받았을 때,
  회원정보를 확인할 필요없이 , 아 우리의 회원이구나를 알 수 있음

<단점>

• 쿠키를 인터럽트해서 가져가서 (해커가) 이걸 요청보내면 되니 , 보안에 매우 강한 것은 아님
  -> solution) HTTPS를 사용하여 요청 자체를 탈취해도 안의 정보를 읽기 힘들게한다.
  세션에 유효시간을 넣어준다.
• 서버에서 레디스를 사용하는데, 추가적으로 비용이 많이 든다.

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

인증에 필요한 정보들을 암호화시킴
AccessToken(JWT 토큰)을 HTTP 헤더에 실어 서버로 보내게 된다.
토큰을 만들기 위해서는 세가지가 필요

• Header : 위 3가지 정보를 암호화할 방식, 타입이 들어감
• payload : 서버에서 보낼 데이터가 들어감, 일반적으로 유저의 고유 ID, 유효기간이 들어감
• Verify Signature : 인코딩한 header, payload 그리고 SECRET KEY시크릿 키를 더한 후 서명됨

HEADER, PAYLOAD 는 인코딩 될뿐이지 암호화되진 않음, 따라서 JWT 토큰에서 headerm, payload 는 누구나 디코딩하여 확인할 수 있음, 하지만 verify Signature은 SECRET KEY를 알지 못하면 복호화 할 수 없음.

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

세션/쿠키 VS JWT

세션/쿠키는 레디스에 유저의 정보를 넣고
JWT는 토큰안에 유저의 정보들을 넣는다.

클라이언트 입장에서는 HTTP 헤더에 세션 ID나 TOKEN에 실어서 보내준다는 점은 동일,
서버 측에서는 인증을 위해 별도의 저장소에 저장하느냐, 암호화를 하느냐에 있음.

참조 : https://tansfil.tistory.com/58?category=475681