토큰 인증방식(+ 쿠키와 세션 추가내용)

쿠키와 세션 궁금증(지난 글 추가내용)

세션이란?

세션은 일정 시간동안(방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점~브라우저를 종료하여 연결을 끝내는 시) 같은 사용자(브라우저)로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술을 의미한다. 혹은 브라우저의 인증을 위해 서버 측에 저장되는 임시 데이터를 세션이라고 한다.

쿠키와 웹 스토리지 차이는?

쿠키	웹 스토리지
정보가 매번 서버에 요청	정보가 서버에 요청되지 않음
저장 가능 크기 작음	쿠키보다 저장가능한 크키가 큼
문자열만 저장가능	JS의 primitives와 Object도 저장가능 (key=value 형태로 저장)
HTML5 이전부터 존재	HTML5 부터 추가

 

가장 큰 차이는 서버에 요청되는지 여부와 저장가능 크기라고 생각한다.

 

웹 스토리지
local storage(로컬 스토리지)	session storage(세션 스토리지)
Persistenct cookie처럼 작동(만료일까지 저장)	Session cookie처럼 작동(브라우저나 탭이 열린 동안에만 저장)

 

내 컴퓨터에 다른 폴더에 쿠키나 웹 스토리지가 저장되는 듯 하다. (브라우저에서 개발자도구 창을 열고 Application 항목에 들어가면 Strorage 확인이 가능하다. Local Storage, Session Storage, Cookies 항목이 나누어져 있는 것을 확인할 수 있다.) 이외에도 클라이언트 측에 indexedDB, Cache Strorage 등 다양한 스토리지가 존재한다. 각 스토리지의 특성을 알고 적절하게 사용하면 될 듯 하다.

세션id가 만료되는 것은 서버가 어떻게 알까? 

답은 알 수 없다!

• 브라우저가 종료되면 쿠키에 저장된 sessionID가 삭제된다. 그렇다고 서버에 있는 sessionID가 삭제되는 것은 아니다. 
• 서버의 세션은 웹 서버에 설정되어 있는 세션 만료시간을 따라가며 그때까지 sessionID는 계속 유지된다.
• 만약 sessionID가 세션 만료시간 전에 다시 접속하면 만료시간이 갱신되어 서버의 sessionID가 유지된다.
• 세션 만료시간이 너무 짧으면 로그인 상태를 유지하기 어렵고, 너무 길다면 서버의 리소스가 소진되는 현상이 발생할 수 있으니 기간을 적절하게 유지하는 것이 필요하다.

해당 내용에 대한 답변이 잘 정리된 블로그 글 : www.kurien.net/post/view/31

---

토큰

왜 토큰을 사용할까? (서버 기반인 세션 인증의 문제점)

서버에서는 세션(유저가 인증하여 접속)을 기록하는데 세션의 수가 늘어난다면 데이터베이스의 리소스를 많이 사용하게 된다. 서버에 무리가 가해지고 서버의 확장이 어렵다. 토큰 기반 인증은 stateless 하다. 토큰은 비공개 키 또는 공개/비공개키를 사용하여 서명된다. 즉, 복호화 할 수 있는 키를 가진 서버라면 어떤 서버든 사용이 가능하다.

이미지 출처:https://velopert.com/2350

 

1. 유저가 로그인을 한다.
2. 서버에서 정보를 검증하고, 유저에게 signed token을 발급한다. (signed의 의미는 해당 토큰이 정상적으로 발급된 토큰임을 증명하는 증명서를 가진다는 것)
3. 유저(클라이언트)가 토큰을 저장하고, 서버 요청시 해당 토큰을 같이 전달한다. (http 헤더에 토큰값을 포함)
4. 서버는 토큰을 검증하여 응답한다.

장점

• 확장성(Scalability)
  서버와 별개로 토큰은 클라이언트 측에 저장되기 때문에 서버의 확장이 가능하다. 세션을 사용할 때처럼 지정된 서버에만 요청되는 것이 아니라 관련 서버 어디에 요청이 가능하다.

• 확장성(Extensibility)
  로그인 정보가 사용되는 분야를 확장하는 것을 의미한다. Google, Github, Naver, Kakao 등의 계정 로그인 방식을 의미한다.
  토큰에 선택적 권한을 부여하여 발급할 수 있다. 예를 들어, 구글 계정 로그인을 했다면 읽기는 가능해도 쓰기는 불가능하게 하는 등의 차별적 권한 부여가 가능하다.

쿠키 비슷하지 않은가?

클라이언트가 정보를 가지고 있고 stateless하며, 서버에 정보를 보내 사용한다는 점에서 쿠키와 비슷하다고 생각했다. 하지만 쿠기와 다른 점은 토큰은 암호화 되어있다는 것이다. 즉, 키를 가진 자만 해당 내용을 복호화하여 사용가능하다. 쿠키와 비슷하지만, 그대로 노출 될 수 있다는 단점이 보완되어 암호화 되어 함부로 노출되어 있지 않다는 장점이 있다.

---

토큰을 사용하는 OAuth는 무엇일까?

OAuth는 인증을 위한 표준 프로토콜이며 http를 사용한다. 예시 중에 로그인을 사원증에 OAuth를 출입증에 비유하는 것이 있다. 사원증과 방문증 받는 것 모두 신원확인을 하기 때문에 인증을 거친다. 인증과 OAuth는 별개의 개념인 것은 아니라는 것이다. OAuth도 인증의 절차를 거친다. 로그인은 인증을 의미하며, User와 Resource Server 사이에 이루어진다. 그리고 User가 Resource server의 서비스를 이용한다. 하지만, OAuth는 User와 Resource Server 사이의 인증을 활용한다. Client가 인증된 User에 대해 Client에서 Resource server의 서비스를 사용한다. Client가 인증 결과를 통해 Resource server의 서비스를 빌려오는 것 같다는 느낌을 받았다. (해당 프로세스는 생활코딩 토큰 부분에 잘 나와있다.)

인증(Authentication)과 허가(Authorization)

• 인증(Authentication) : 누구인지 확인하는 절차
• 인가, 허가(Authorization) : 권한을 허락하는 것

OpenID와 OAuth?

OpenID, OAuth 모두 인증을 위한 프로토콜이며, http를 사용한다. 하지만 목적성이 다르다. OpenID의 주요 목적은 인증이며 본질적으로 로그인과 같다. OpenID Provider에게 인증을 위임한다. OAuth의 주요 목적은 권한(Authorization)이 있는 사용자인지를 확인하는 것이다. 해당 서비스 및 API를 사용할 수 있는 사용자인지를 확인하는데 목적이 있다.

용어

• User: Service Provider에 계정이 있으면서 Consumer를 이용하려는 사용자
• Consumer: Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스
• Service Provider: OAuth 기능을 사용하는 OpenAPI를 제공하는 서비스
• Request Token: Service Provider에게 접근권한을 인증받기 위해 사용하는 값. 인증 후에는 Access Token으로 교환
• Access Token: 인증 후, Service Provider의 자원에 접근하기 위한 키를 포함한 값

OAuth의 인증과정

이미지 출처: https://d2.naver.com/helloworld/24942

1. Consumer: 사용자가 (API를 제공하는)서비스에게 Request Token을 요청한다.
2. Service Provider: Request Token을 발급한다.
3. Consumer: 사용자 인증 페이지를 호출하여 인증을 한다.
4. Service Provider: 사용자의 인증 정보를 확인하고, 권한 요청을 수락한다. Access Token을 발급한다.
5. Consumer: Access Token을 가지고 서비스를 이용한다.

참고

쿠키와 웹 스토리지 참고 글
제로초 쿠키와 로컬스토리지
벨로퍼트 토큰 블로그 글
OAuth naverD2 글
OAuth 생활코딩

http 통신간의 쿠키와 세션의 동작방식