어제, 오늘 그리고 내일

Part 1. JWT’s Basic Information

JSON Web Token

JSON 포맷을 이용한 Web Token

Claim based Token

두 개체에서 JSON 객체를 이용해 Self-contained 방식으로 정보를 안전하게 전달

회원 인증, 정보 전달에 주로 사용

RFC 7519

Claim based?

Claim : 사용자에 대한 프로퍼티 / 속성

토큰 자체가 정보

Self-contained : 자체 포함, 즉 토큰 자체가 정보

key / value

Part 2. Web Token

웹 토큰의 필요성

CSRF, 기존 시스템의 보안 문제

CORS, 도메인 확장 시 api로서의 문제

Web, Mobile 등 다양한 클라이언트

Session의 한계

Scale out의 한계

REST API : REST API는 Stateless를 지향

현재 우리는?

그런데 아직도 Cookie??

쿠키 기반 로그인의 문제점은 너무 많다

Server side Session 기반으로 넘어갈 것인가?

쿠키 기반 인증은 두말할 것 없이 변경해야 하고, 보편적 Session으로 갈 것인가?

Part 3. Type of Authorization

Cookie - Client Side Storage

문제점 투성이

Session - Sever Side Authorization

Cookie와 차이점은 Cookie는 정보를 클라이언트에 저장하고 Session은 정보를 서버에 저장한다.

Session Problem 1 - 서버 확장 시 세션 정보의 동기화 문제

서버가 스케일 아웃돼서 여러 개가 생기면 각 서버마다 세션 정보가 저장된다.
로그인 시(서버 1), 새로고침(서버 2)으로 접근하면 서버는 인증이 안됐다고 판단한다.

Session Problem 2 - 서버 / 세션 저장소의 부하

세션을 각 서버에 저장하지 않고 세션 전용 서버, DB에 저장해도 문제가 생긴다.
모든 요청 시 해당 서버에 조회해야 한다. DB 부하를 야기할 수 있다.

Session Problem 3 - 웹 / 앱 간의 상이한 쿠키-세션 처리 로직

기존의 Client는 웹 브라우저가 유일했다. 그러나 이제는 모바일로 접근하는 경우도 처리해야 한다.
웹 / 앱의 쿠키 처리 방법이 다르고 또 다른 Client 가 생겨나면 쿠키-세션에 맞게 처리해야 한다.

Token - Self-contained & Stateless

앞의 문제를 해결하는 최선의 방법은 토큰이다.
토큰은 서버의 상태를 저장하지 않는다. 토큰 자체로 정보를 가지고 있기 때문에 별도의 인증서버가 필요 없다. 따라서 요청을 받을 서버 자체에서 인증 프로세스를 수행할 수 있다.
또한, JSON 포맷으로 통신하기 때문에 어떤 Client 에서든 Data 통신에 JSON을 이용하면 토큰을 이용할 수 있다.

Part 4. JWT’s Architecture

JWT의 기본 구조

Header . Payload . Signature

Header

JWT 웹 토큰의 헤더 정보

typ : 토큰의 타입, JWT만 존재

alg : 해싱 알고리즘. (HMAC SHA256 or RSA). 헤더를 암호화하는 게 아니다. 토큰 검증 시 사용.

{
     "alg" : "HS256",
     "typ" : "JWT"
}

위의 내용을 base64로 인코딩한다. => eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
base 64는

Payload

실제 토큰으로 사용하려는 데이터가 담기는 부분. 각 데이터를 Claim이라고 하며 다음과 같이 3가지 종류가 있다.

Reserved claims

 : 이미 예약된 Claim. 필수는 아니지만 사용하길 권장. key는 모두 3자리 String이다.

iss (String) : issuer, 토큰 발행자 정보

exp (Number) : expiration time, 만료일

sub (String) : subject, 제목

aud (String) : audience,

More

Public claims

 : 사용자 정의 Claim.

Public이라는 이름처럼 공개용 정보

충돌 방지를 위해 URI 포맷을 이용해 저장한다.

Private claims : 사용자 정의 Claim

Public claims과 다르게 사용자가 임의로 정한 정보

아래와 같이 일반 정보를 저장한다.

• {
      "name" : "hak",
      "age"  : 26,
  }
  

Signature

Header와 Payload의 데이터 무결성과 변조 방지를 위한 서명
Header + Payload를 합친 후, Secret 키와 함께 Header의 해싱 알고리즘으로 인코딩

HMACSHA256(   base64UrlEncode(header) + "." +   base64UrlEncode(payload),   secret)

JWT 구조

JWT는 [Header Payload Signature] 각각 JSON 형태의 데이터를 base 64 인코딩 후 합친다.
아래와 같은 순서로. 을 이용해 합친다.
최종적으로 만들어진 토큰은 HTTP 통신 간 이용되며, Authorization이라는 key의 value로서 사용된다.

JWT 인증 과정

Part 5. Is JWT a Silver bullet?

그렇다면 모든 서비스들은 기존의 쿠키-세션 기반에서 웹 토큰 기반의 인증으로 변경해야 할까?

JWT의 단점 & 도입 시 고려사항

Self-contained : 토큰 자체에 정보가 있다는 사실은 양날의 검이 될 수 있다.

토큰 길이 : 토큰 자체 payload에 Claim set을 저장하기 때문에 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.

payload 암호화 : payload 자체는 암호화되지 않고 base64로 인코딩한 데이터다.
중간에 payload를 탈취하면 디코딩을 통해 테이터를 볼 수 있다.
JWE를 통해 암호화하거나, payload에 중요 데이터를 넣지 않아야 한다.

Stateless : 무상태성이 때론 불편할 수 있다. 토큰은 한번 만들면 서버에서 제어가 불가능하다.
토큰을 임의로 삭제할 수 있는 방법이 없기 때문에 토큰 만료시간을 꼭 넣어주는 게 좋다.

tore Token : 토큰은 클라이언트 side에서 관리해야 하기 때문에 토큰을 저장해야 한다.

Conclusion

HTTP, REST API의 공통적인 특징은 Stateless(무상태)를 지향한다는 것이다.
Stateful, 즉 상태를 저장하는 서버는 많은 Side-effect를 발생시킬 수 있다.
또한, 서론에 말했듯이 현재의 IT 인프라 구조는 유연한 확장 가능성이 있어야 하는데 기존의 쿠키-세션 기반의 인증을 사용하면 확장 가능한 인프라를 구성하기 힘들다.
기존의 로그인 / 인증을 모두 Web Token 기반으로 변경할 수는 없지만, 앞으로 만들게 될 서비스 특히 RESTful 한 API의 인증에는 JWT를 사용해보는 것이 좋을 것이라 생각한다.
( JWT 인증 예제 - https://github.com/SangHakLee/nodejs-jwt-example-ryan).

 Reference

1. https://sanghaklee.tistory.com/47 [이상학의 개발 블로그]

#. CBOR

CBOR 이란 Concise Binary Object Representation의 약자로 간결한 이진 객체의 형태 표현으로 보시면 됩니다.

쉽게 JSON, XML과 같은 데이터 표현의 한 방법인 것이죠.

하지만 Binary 데이터 이기 때문에 다른 표현 방식보다 가벼운 것이 장점입니다.

자세한 설명은 아래의 Link를 참고하세요.

Link : http://cbor.io/

CDN

콘텐츠 전송 네트워크(Content delivery network 또는 content distribution network (CDN))는 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말합니다. 즉, 지리적으로 여러 개로 분산된 서버를 말합니다. 인터넷 서비스 제공자에 직접 연결되어 데이터를 전송하므로, 콘텐츠 병목을 피할 수 있는 장점이 있습니다.

CDN의 목적은 높은 사용성과 효율로 사용자에게 콘텐츠를 전달함에 있습니다. CDN은 오늘날 인터넷에 존재하는 콘텐츠의 상당수를 서비스하고 있는데 이에는 웹 요소 (텍스트, 그래픽, 스크립트), 다운로드 가능한 요소 (미디어 파일, 소프트웨어, 문서), 애플리케이션 (전자상거래, 포털), 실시간 미디어, 주문형 스트리밍, 그리고 소셜 네트워크 등이 있습니다.

미디어 회사나 전자상거래 업체와 같은 콘텐츠 제공자는 그들의 콘텐츠를 사용자들에게 전달하기 위해서 CDN 회사에 사용료를 지불한다. 반대로, CDN은 ISP, 이동통신사업자, 그리고 네트워크 사업자들에게 데이터 센터에서의 서버 호스팅 비용을 지불합니다. 더 나은 퍼포먼스와 사용성 이외에도 CDN은 콘텐츠 제공자의 서버의 트래픽을 덜어주어 콘텐츠 제공자의 비용을 줄여줍니다. 추가로, CDN은 대규모 분산 서버 장비로 공격 트래픽을 완화할 수 있으므로 콘텐츠 제공자에게 DoS 공격에 대해서 어느 정도 보호해 줄 수 있습니다. 초기 대부분의 CDN은 CDN이 소유하고 동작하는 서버를 사용하는 콘텐츠만 서비스하였으나 최신 트렌드는 P2P 기술을 이용하는 하이브리드 모델을 사용하는 것입니다. 하이브리드 모델에서 콘텐츠는 지정된 서버 그리고 주변 컴퓨터(peer-user-owned)를 모두 사용합니다.

CDN의 사례

인터넷 콘텐츠의 상당 부분이 CDN을 통해 전송됩니다. 간단한 사례를 통해 설명드리겠습니다.
뉴욕에 있는 사용자가 런던에 있는 업체의 웹사이트를 보고 싶어 합니다. 이 웹사이트는 영국의 서버에 호스팅되어 있습니다. 해당 사용자가 뉴욕에서 영국까지 대서양을 가로질러 요청을 보낸다면 웹사이트의 콘텐츠 로딩 시간은 길어질 것입니다. CDN은 이런 문제를 해결하기 위해 런던 웹사이트 콘텐츠를 캐싱해 전 세계 여러 곳의 ‘PoP(Points of Presence)’에 저장합니다. 이러한 PoP는 자체 캐싱 서버를 갖고 있으며 뉴욕에 있는 사용자에게 해당 콘텐츠를 전송합니다.
사용자의 물리적 위치와 가장 가까운 서버에서 전송되는 콘텐츠는 더 빠른 고성능 웹 경험을 제공합니다.

CDN의 작용 원리

CDN의 미션은 지연 시간을줄이는 것입니다. 지연 시간은 웹 페이지 또는 비디오 스트리밍 콘텐츠가 디바이스에 완전히 로딩되기 전에 발생하는 불편한 지연을 의미합니다. 지연 시간은 밀리초 단위로 측정됩니다. 하지만 사용자가 체감하는 시간은 매우 길며, 시간 초과 또는 로딩 오류가 발생할 수 있습니다. 콘텐츠가 사용자에게 도달하기 위해 이동해야 하는 물리적 거리를 줄여 지연 시간을 줄이는 콘텐츠 전송 네트워크도 있습니다. 따라서 CDN이 보다 광범위하고 넓게 분산되어 있으면 사용자와 최대한 가까운 곳에 콘텐츠를 배치함으로써 웹 콘텐츠를 보다 빠르고 안정적으로 전송할 수 있습니다.

주말에 최근 개봉한 할리우드 영화를 보고 싶다면 CDN을 통해 해당 비디오를 제공할 최적의 서버를 네트워크에서 찾을 수 있습니다. 이 서버는 일반적으로 사용자의 물리적 위치와 가장 가까운 서버가 됩니다. 미디어 파일은 캐싱되며 동일한 지역의 다른 사용자가 해당 미디어 파일을 요청할 경우에 대비해 콘텐츠 전송 네트워크 서버에 남게 됩니다. 요청한 콘텐츠가 오래되었거나 사용할 수 없는 경우, CDN 서비스는 새로 가져온 콘텐츠를 저장하고 향후 요청에 있을 때 전송합니다.

웹사이트 콘텐츠 전송은 CDN에서 흔히 사용되는 기능이지만, 유일한 기능은 아닙니다. CDN은 4K 및 HD 품질의 비디오, 오디오 스트림, 앱·게임·OS 업데이트와 같은 소프트웨어 다운로드 등 광범위한 콘텐츠를 전송합니다. 즉, 디지털화할 수 있는 모든 데이터를 콘텐츠 전송 네트워크를 통해 전송할 수 있습니다.

Reference

1. CDN이란 무엇인가요? | Akamai 참고 자료