사용자 인증 방식

https://github.com/im-d-team/Dev-Docs/blob/master/Network/%EC%82%AC%EC%9A%A9%EC%9E%90%20%EC%9D%B8%EC%A6%9D%20%EB%B0%A9%EC%8B%9D(Cookie,%20Session%20&%20oAuth%202.0%20&%20JWT).md

1. 서버 기반 인증(cookie-session)

• 설명: 전통적인 방식이다. HTTP의 stateless한 속성을 보완할 필요성이 생겨서 탄생했다.
• 장점: stateful 유지 가능
• 단점: 서버 부하 (유저의 인증 정보를 서버측에 담아둠)
  stateful: server side 에 client와 server의 연속된 동작 상태정보를 저장하는 형태
  stateless: server side 에 client와 server의 연속된 동작 상태정보를 저장하지 않는 형태

세션이란

• 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술
• 쿠키 로그인 예제에서 확인했듯이 쿠키는 사용자의 정보를 사용자 컴퓨터 메모리에 저장하지만 세션은 서버측에 저장

세션을 사용한 로그인 구현

1. 로그인 성공 시 세션을 하나 생성
   이 세션의 Key 값은 UUID(중복되지 않는 랜덤값, 예측 불가)으로 설정
   Value 값에 사용자 정보를 넣음
2. 생성한 세션을 서버측 세션 저장소에 보관
3. 세션의 Key값(UUID)을 쿠키를 통해 사용자에게 전달
4. 사용자는 로그인 성공 이후 다른 요청을 할 때마다 이 쿠키를 서버에 같이 보내줌
5. 서버 측에서 사용자에게 쿠키를 통해 UUID값을 받는다면, 전달받은 UUID를 Key 값으로 갖는 세션을 서버측 세션 저장소에서 검색
6. 세션 저장소에 Key값이 일치하는 세션이 있다면, 그 세션의 Value값에는 로그인 한 사용자의 정보가 들어있고, 이 정보를 통해 인증, 인가 진행

   쿠키 로그인 방식과는 달리 세션의 Key값이 예측 불가능하기 때문에 다른 사용자인 것 처럼 요청을 보내는 것이 불가능 하다는 장점이 있지만 동시 사용자 수가 많아진다면 서버에 저장해야 할 세션의 수가 많아진다는 단점도 존재

2. 토큰 기반 인증

• 설명: 서버 기반 인증 방식과 달리 stateless한 방식이다. 서버 부하를 덜 수 있다.
  
  
• 설명: Access Token, Refresh Token을 이용한 인증 방식은 한 서버에서 모두 관리하는 반면, 여기 OAuth에서는 Authorization Server에서 인증+권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 한다.
• 장점: 보안성 좋다. (Access Token을 지속적으로 발급받아야 하므로)
• 단점: 필요한 Resource가 너무 많다. Access Token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP 요청이 잦다.
• Access Token: API를 요청할 때 사용하는 토큰. 유효기간이 짧다.
• Refresh Token: Access Token의 유효기간이 만료되면 Access Token을 다시 발급받기 위해 사용되는 Token. Access Token보다 유효기간이 길다.

JWT (JSON Web Token)

• 설명: 토큰 자체가 data를 가지고 있다.
• 장점: 토큰 기반 인증의 장점 (서버 부하 덜 수 있음)
• 단점: Packet(보내는 데이터) 양이 크다. 토큰 자체를 탈취하면 ID, PW 자체를 알 수 있다. (따라서 HTTPS 통신을 권장한다.)
  https://jwt.io/

https://www.youtube.com/watch?v=XXseiON9CV0
https://www.youtube.com/watch?v=tosLBcAX1vk