Cookie, Session, Token, OAuth

1. Cookie

• 서버에서 클라이언트에 영속성있는 데이터를 저장하는 방법
• 서버는 클라이언트의 쿠키를 이용하여 데이터를 가져올 수 있으며 클라이언트에 특정한 데이터를 저장할 수도 있다.
  
  • 이 때, 데이터를 저장한 이후 특정 조건들이 만족되어야 데이터를 다시 가져올 수 있다.
  • 이러한 조건들은 http 헤더를 이용해 쿠키 옵션으로 표현할 수 있다.

 

1-1. 쿠키 옵션

• Domain
  • www.google.com과 같이 서버에 접속할 수 있는 이름
  • 포트, 서브 도메인 정보, 세부 경로를 포함하지 않음
  • 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키 전송 가능
• Path
  • 세부 경로. 서버가 라우팅할 때 사용하는 경로
  • http://www.localhost.com:3000/aaa/bbb에서 path(세부 경로)는 /aaa/bbb이다. 만약 명시하지 않았다면 "/"으로 설정

 

• MaxAge, Expires
  • 쿠키가 유효한 기간을 정하는 옵션.
  • MaxAge: 쿠키가 유효한 시간을 초 단위로 설정하는 옵션 (타이머같이)
  • Expires: 언제까지 쿠키가 유효한지 지정하는 옵션 (달력에 체크하는 것 같이)
    • 세션 쿠키: 위의 두 옵션이 없는 쿠키. 브라우저를 종료하면 해당 쿠키는 삭제된다.
    • 영속성 쿠키: 위의 두 옵션이 있는 쿠키. 유효한 시간만큼 사용 가능
• Secure
  • 사용하는 프로토콜에 따른 쿠키의 전송 여부를 결정하는 옵션
  • 값이 true라면 HTTPS를 이용하는 경우에만 쿠키 전송 가능
  • 해당 옵션이 없거나 false라면 https://어떤주소.com, http://어떤주소.com 모두 쿠키 전송 가능
  • 도메인이 localhost인 경우에는 HTTPS가 아니라도 쿠키 전송 가능
• HttpOnly
  • 자바스크립트로 브라우저의 쿠키에 접근 가능한지 여부
  • 값이 true라면 자바스크립트로 접근 불가.
• SameSite 
  • same-site: 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우
  • Cross-Origin: 저 셋 중 하나라도 다른 경우. 
  • Cross-Origin 요청을 받은 경우, 요청에서 사용한 메소드(GET, POST, PUT 등)와 해당 옵션의 조합을 기준으로 서버의 쿠키 전송 여부를 결정. 
    • Lax: Cross-Origin 요청이라면 GET 메소드에 대해서만 쿠키 전송 가능
    • Strict: 가장 엄격한 옵션. Cross-Origin이 아닌 same-site인 경우에만 쿠키 전송 가능
    • None: 가장 관대한 옵션. 항상 쿠키 전송 가능. Secure 옵션이 필요함

 

2. Session

• Session: 서버가 Client가 Client에 유일하고 암호화된 ID를 부여하는 것. 중요 데이터는 서버에서 관리.

 

2-1. Session-based Authentication (세션 기반 인증)

• 로그인
  • 사용자가 정확한 이이디와 비밀번호를 입력했을 경우, 서버는 인증(Authentication)에 성공했다고 판단  => 세션
  • 각 세션을 구분하기 위한 세션 아이디를 만들고 클라이언트에 세션 성공을 증명할 수단으로 세션 아이디를 쿠키를 이용해 전달
• 로그아웃
  • 세션 아이디로 인증 여부 판단 후, 서버에서는 세션 정보를 삭제하고 클라이언트에서는 쿠키를 갱신하거나 삭제

 

3. Token

• 세션 기반 인증이 가지고 있던 한계를 극복하고자 고안.
  • 세션 기반 인증은 서버에서 유저의 상태를 관리함 => 서버에 부담이 될 수 있음 => 클라이언트에 이를 저장
  • 세션 인증 방식과 비교해 서버의 부하나 메모리 부족 문제를 줄일 수 있음
• 토큰: 인증과 권한 정보를 담고 있는 암호화된 문자열

 

3-1. 토큰 인증 방식의 흐름

600

1. 사용자가 인증 정보를 담아 서버에 로그인 요청을 보냄
2. 서버는 데이터베이스에 저장된 사용자의 인증 정보를 확인
3. 인증에 성공했다면 해당 사용자의 인증 및 권한 정보를 서버의 비밀 키와 함께 토큰으로 암호화
4. 생성된 토큰을 클라이언트로 전달
   • HTTP 상에서 인증 토큰을 보내기 위해 사용하는 헤더인 Authorization 헤더를 이용하거나 쿠키 등으로 전달
5. 클라이언트는 전달 받은 토큰을 저장
   • 저장하는 위치는 Local Storage, Session Storage, Cookie 등 다양함
6. 클라이언트가 서버로 리소스를 요청할 때 토큰을 함께 전달
   • 토큰을 보낼 때에도 Authorization 헤더를 사용하거나 쿠키로 전달 가능
7. 서버는 전달받은 토큰을 서버의 비밀 키를 통해 검증. 이를 통해 토큰이 위조되었는지 혹은 토큰의 유효 기간이 지나지 않았는지 등을 확인할 수 있음
8. 토큰이 유효하다면 클라이언트의 요청에 대한 응답 데이터를 전송

 

3-2. 토큰 인증 방식의 장점

• 무상태성: 서버가 유저의 인증 상태를 관리하지 않기 때문에 서버는 비밀 키를 통해 클라이언트에서 보낸 토큰의 유효성만 검증하면 된다. 이를 통해 무상태적인 아키텍처 구축이 가능하다.
• 확장성: 다수의 서버가 공통된 세션 데이터를 가질 필요가 없기에 서버를 확장하기 용이
• 어디서나 토큰 생성 가능
• 권한 부여에 용이: 토큰은 다양한 정보를 담을 수 있기 때문에 사용자 권한 부여에 용이하다.

 

4. Oauth

• 인증을 중개해주는 메커니즘. 보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜. 
• 즉, 이미 사용자 정보를 가지고 있는 웹 서비스에서 사용자의 인증을 대신해주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용에 서버에서 인증을 할 수 있다.

 

4-1. OAuth의 주체

Resource Owner

• Resource Owner (사용자)
  • OAuth 인증을 통해 소셜 로그인을 하고 싶어하는 사용자
  • Resource는 사용자의 이름, 전화번호 등의 정보를 의미

 

Application

• Application (새로 이용하고 싶은 서비스)
  • 사용자가 소셜 로그인을 활용해 이용하고자하는 새로운 서비스

 

Resource Server & Authorization Server

• Resource Server & Authorization Server
  • Resource Server: 사용자가 소셜 로그인을 하기 위해서 사용하는, 이미 사용중인 서비스의 서버 중 사용자의 정보를 저장하고 있는 서버
  • Authorization Server: 이미 사용중인 서비스의 서버 중 인증을 담당하는 서버

 

4-2. OAuth 인증 방식의 종류와 흐름

• Grant Type: Authorization Server에서 Access Token을 받아오는 방식

 

Implicit Grant Type

• Implicit Grant Type
  1. 사용자가 Application에 접속
  2. Application에서 Authorization Server로 인증 요청을 보냄
  3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 액세스 토큰을 발급
  4. Authorization Server에서 Application으로 액세스 토큰을 전달
  5. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청
  6. Resource Server는 Application에게서 전달 받은 액세스 토큰이 유효한 토큰인지 확인
  7. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달

 

• Authorization Code Grant Type
  1. 사용자가 Application에 접속
  2. Application에서 Authorization Server로 인증 요청을 보냄
  3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 Authorization Code를 발급
  4. Authorization Server에서 Application으로 Authorization Code를 전달
  5. Application이 Authorization Code로 발급받은 Authorization Code를 전달
  6. Authorizaiton Server는 유효한 Authorization Code인지 확인한 후 액세스 토큰을 발급
  7. Authorization Server에서 Application으로 액세스 토큰을 전달
  8. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청
  9. Resource Server는 Application에게서 전달 받은 액세스 토큰이 유효한 토큰인지 확인
  10. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달

 

Refresh Token Grant Type

• Refresh Token Grant Type
  1. Authorization Server로 리프레시 토큰 전달
  2. 토큰 검증 후 Access Token 전달
  3. Application은 이를 이용해 Resource Servers에서 사용자 정보를 받아옴

 

4-3. OAuth의 장점

• 쉽고 안전하게 새로운 서비스 이용 가능
• 권한 영역 설정 가능