상태 유지 기술

HTTP 통신은 stateless한 특징을 가져 클라이언트의 정보를 저장하지 않고 항상 새로운 연결로 생각
→ 어떻게 클라이언트를 특정할 수 있을까

Cookie

• 서버가 클라이언트에 흔적을 남긴다
• 유효기간이 지나면 사라진다
• key와 value 쌍으로 정보를 저장
• Domain, Path, Max-Age/Expires, Secure 등의 속성을 저장 가능
• 쿠키는 클라이언트에 저장하는만큼 위변조가 가능하고 다른 사람이 훔쳐갈 수도 있다 (중요한 정보가 담기면 위험)

동작 방법

• 클라이언트에서 생성되거나 서버에서 생성되어 클라이언트에 저장
• 저장된 쿠키는 다시 해당하는 웹페이지에 접속할 때 브라우저에서 서버로 쿠키를 전송

Session

• 쿠키처럼 사용자의 데이터를 기록하지만 클라이언트에 남기는 것이 아니라 서버에 남긴다
• 서버가 종료되거나 유효기간이 지나면 사라진다
• 서버에는 데이터를 저장하는게 불가 → 사용자를 어떻게 특정할 수 있을까 → 쿠키를 발급!

Session Cookie

• 접속하는 모든 이에게 쿠키를 발급하고 쿠키를 통해 동일인물임을 보장받음

동작 방법

• 클라이언트가 서버에 요청을 보내면 서버는 클라이언트를 식별하는 session id를 생성
• 서버는 session id를 이용해 key와 value의 session을 생성
• 서버는 session id를 저장하는 쿠키를 생성해 클라이언트에 전송
• 클라이언트는 서버에 요청을 보낼때 해당 쿠키를 전송
• 서버는 사용자의 세션 쿠키에 있는 session id를 사용해 그 전 요청에서 생성한 session을 찾고 사용

세션	쿠키
브라우저 종료 시 종료	브라우저가 종료되도 유지 가능
서버에 저장	클라이언트에 저장
서버쪽에 저장되어 서버가 뚫리지 않는 이상 위변조 불가	클라이언트측에 저장되어 위변조 가능
비교적 느린편 (비슷)	비교적 빠른편 (비슷)
서버에서 처리해 사용자가 많고 담는 객체가 커질수록 부하가 커짐	서버에 부담을 주지 않음

OAuth

제 3의 서비스에서 Resource Owner의 인증을 거쳐 Resource Server에 리소스를 요청할 수 있다

Client

• 소셜 인증을 사용하고자하는 서비스
• Resource Server측에 미리 등록해서 로그인이 가능하도록 설정

Resource Owner

• 서비스에 접근하고자하는 유저
• Client가 부여한 url로 접속해 소셜 로그인
• authorization code가 포함된 주소로 redirect

Resource Server

• 데이터를 가지고있는 서버
• Client에서 authorization code, client secret을 사용해 token을 요청하면 토큰 발급

Access Token

• Resource Server에서 생성 후 Client에서 토큰 저장
• Client가 해당 access token으로 Resource Server에 접속하면 해당 user임을 판별

Refresh Token

• Access Token을 사용해 API호출
• 유효 기간이 지난 후 Refresh Token을 서버에 전달해 Access Token을 다시 발급받음 (refresh token도 access token처럼 갱신되는 경우도 있고 refresh token을 계속 유지하는 경우도 있음)