프론트엔드Explorer

JWT에 대해 알아보기 전에, 모던 웹서비스에 많이 사용되고 있는 '토큰(Token) 기반 인증'에 대해 먼저 알아보자. 

API를 사용하는 웹서비스를 개발한다면, 토큰을 사용하여 유저들의 인증 작업을 처리하는 게 가장 좋다. 

토큰 기반 인증 시스템을 선택하는 것에는 여러가지 이유가 있다. 

그 중 주요 이유들은 아래와 같다. 

Stateless 서버

Stateless 서버를 이해하려면, Stateful 서버가 무엇인지 알아야 한다. 

Stateful 서버는 클라이언트에게서 요청을 받을 때마다, 클라이언트의 상태를 계속해서 유지하고, 이 정보를 서비스 제공에 이용한다. 

Stateful 서버의 예제로는 세션을 유지하는 웹서버가 있다. 

예를 들어 유저가 로그인을 하면, 세션에 로그인이 되었다고 저장을 하고,

서비스를 제공할 때 그 데이터를 사용한다. 

여기서 이 세션은, 서버컴퓨터의 메모리에 담을 때도 있고, 데이터베이스 시스템에 담을 때도 있다. 

반대로, Stateless 서버는 상태를 유지하지 않는다. 

상태 정보를 저장하지 않으면, 서버는 클라이언트 측에서 들어오는 요청으로만 작업을 처리한다. 

이렇게 상태가 없는 경우, 클라이언트와 서버의 연결고리가 없기 때문에 

서버의 확장성(Scalability)이 높아진다. 

모바일 어플리케이션에 적합하다

Android/ios 모바일 어플리케이션을 개발할 때, 안전한 API를 만들기 위해서 쿠키 같은 인증시스템은 이상적이지 않다. (쿠키 컨테이너를 사용해야 하기 때문에) 

토큰 기반 인증을 도입한다면, 더욱 간단하게 번거로움을 해결할 수 있다. 

인증 정보를 다른 어플리케이션으로 전달할 수 있다

대표적인 예제로, OAuth가 있다. 

페이스북/구글 같은 소셜 계정들을 이용하여 다른 웹서비스에서도 로그인할 수 있게 할 수 있다. 

보안

토큰 기반 인증 시스템을 사용하여 어플리케이션의 보안을 높일 수 있다. 

단, 이 토큰 기반 인증을 사용한다고 해서 무조건 해킹의 위험에서 벗어나는 건 아니다.

왜 토큰을 사용하게 되었을까?

토큰 기반 인증 시스템은 어떻게 나타나게 되었을까? 

이를 알아보기 위해서, 과거의 인증시스템이 어떤 방식으로 작동했는지 먼저 살펴보자.

서버 기반 인증

기존의 인증 시스템에서는 서버에서 유저들의 정보를 기억하고 있어야 한다. 

이 세션을 유지하기 위해서는 여러 방법이 사용된다. 

메모리 / 디스크 / 데이터베이스 시스템에 이를 담는다. 

서버 기반 인증 시스템의 흐름은 다음과 같다. 

이런 방식의 인증 시스템은 아직도 많이 사용되고 있다. 

하지만, 요즘 웹어플리케이션들이 부흥하면서, 이런 방식의 인증 시스템은 문제를 보이기 시작했다. 

예를 들면, 서버를 확장하기가 어렵다. 

서버 기반 인증의 문제점 

세션

: 유저가 인증을 할 때, 서버는 이 기록을 서버에 저장해야 한다. 이를 세션이라고 부른다.

대부분의 경우에는 메모리에 이를 저장하는데, 로그인 유저의 수가 늘어난다면 어떻게 될까?

서버의 램이 과부하될 것이다. 이를 피하기 위해, 세션을 데이터베이스 시스템에 저장하는 방식도 있지만, 

이 또한 유저의 수가 많으면 데이터베이스 성능에 무리를 줄 수 있다. 

확장성

: 세션을 사용하면 서버를 확장하는 것이 어려워진다. 여기서 서버의 확장이란, 

단순히 서버의 사양을 업그레이드 하는 것이 아니라 더 많은 트래픽을 감당하기 위해

여러 개의 프로세스를 돌리거나, 여러 대의 서버 컴퓨터를 추가하는 것을 의미한다.

세션을 사용하면서 분산된 시스템을 설계하는 게 불가능한 것은 아니지만, 과정이 매우 복잡해진다. 

CORS(Cross-Origin Resource Sharing)

: 웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 

작동하도록 설계되어 있다. 따라서, 쿠키를 여러 도메인에서 관리하는 것은 좀 번거롭다. 

토큰 기반 시스템의 작동원리

토큰 기반 시스템은 stateless하다. 즉, 상태 유지를 하지 않는다. 

이 시스템에서는 더 이상 유저의 인증 정보를 서버나 세션에 담아두지 않는다. 

이거 하나만으로도 위에서 서술한 서버에서 유저의 인증 정보를 서버측에 담아둠으로

발생하는 많은 문제점들이 해소된다. 

세션이 존재하지 않으니, 유저들이 로그인 되어있는지 아닌지 신경 쓰지 않으면서

서버를 손쉽게 확장할 수 있을 것이다. 

토큰 기반 시스템의 구현 방식은 시스템마다 크고 작은 차이가 있겠지만, 

대략 다음과 같다. 

1. 유저가 아이디와 비밀번호로 로그인한다. 
2. 서버에서 해당 계정 정보를 검증한다.
3. 계정 정보가 정확하다면, 서버측에서 유저에게 signed 토큰을 발급해준다. (signed는, 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature를 지니고 있다는 뜻이다) 
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할때마다 해당 토큰을 서버에 함께 전달한다. 
5. 서버는 토큰을 검증하고, 요청에 응답한다. 

웹서버에서 토큰을 서버에 전달할 때는, HTTP 요청의 헤더에 토큰 값을 포함시켜 전달한다. 

토큰의 장점

무상태(Stateless), 확장성(Scalability)

Stateless와 Scalability는 토큰 기반 인증 시스템의 중요한 속성이다. 

토큰은 클라이언트사이드에 저장하기 때문에 완전히 stateless하며,

서버를 확장하기에 매우 적합한 환경을 제공한다. 

만약, 세션을 서버에 저장하고 있고, 서버를 여러 대 사용하여 요청을 분산했다면, 

어떤 유저가 로그인 했을 때, 그 유저는 처음 로그인했던 그 서버에만 요청을 보내도록 설정을 해야 한다. 

하지만, 토큰을 사용한다면 어떤 서버로 요청이 들어가든 상관 없다. 

보안성

클라이언트가 서버에 요청을 보낼 때, 더 이상 쿠키를 전달하지 않음으로

쿠키를 사용함으로 인해 발생하는 취약점이 사라진다. 

하지만, 토큰을 사용하는 환경에서도 취약점이 존재할 수 있으니,

언제나 취약점에 대비해야 한다. 

Extensibility(확장성)

여기서의 확장성은, Scalability와는 또 다른 개념이다. 

Scalability는 서버를 확장하는 걸 의미하지만, 

Extensibility는 로그인 정보가 사용되는 분야를 확장하는 것을 의미한다. 

토큰을 사용하여 다른 서비스에서도 권한을 공유할 수 있다. 

예를 들어, 로켓펀치에서는 Facebook, LinkedIn, GitHub, Google 계정으로 로그인할 수 있다. 

토큰 기반 시스템에서는, 토큰에 선택적인 권한만 부여하여 토큰을 발급할 수 있다.

(예를 들어, 로켓펀치에서 Facebook 계정으로 로그인을 했다면, 프로필 정보를 가져오는 권한은 있어도, 포스트를 작성할 수 있는 권한은 없다)  

여러 플랫폼 및 도메인

서버 기반 인증 시스템의 문제점 중 하나는 CORS이다. 

어플리케이션과 서비스의 규모가 커지면, 여러 디바이스를 호환시키고,

더 많은 종류의 서비스를 제공하게 된다.

토큰을 사용하면, 그 어떤 디바이스에서도, 그 어떤 도메인에서도, 

토큰만 유효하다면 요청이 정상적으로 처리된다. 

서버에서 어플리케이션의 응답 부분에 다음 헤더만 포함시켜주면 된다.

Access-Control-Allow-Origin: *

이번 포스트에서는 토큰 기반 인증 시스템과 기존의 시스템과 어떤 차이가 있는지 알아보았다. 

다음 포스트에서는 JWT에 대해 본격적으로 알아보도록 하자. 

위 포스팅은 아래 링크를 참고하여 작성했습니다. 

https://velopert.com/2350?openLinerExtension=true

TypeScript는 왜 사용할까?

버그를 줄일 수 있기 때문에 유지보수가 쉬워지고, 이는 곧 질 좋은 코드이니까! 

TypeScript는 JavaScript의 Superset!

TypeScript는 완전히 새로운 언어가 아니다. 

JavaScript를 기반으로 한 언어라는 뜻. 

TypeScript는 JavaScript 코드를 보다 쉽게, 강력하게 작성하도록 도와주는 좀 더 나은 버전의 JavaScript이다. 

TypeScript의 특징: 타입 표기

JavaScript와는 달리, 변수를 정의할 때 데이터 타입을 지정할 수 있다. 

타입을 표기하면 코드가 좀 더 예측 가능하며, 디버깅하기가 쉽다. 

아래 코드를 보면, 왜 타입을 표기하는 것이 좋은지 알 수 있다. 

// JavaScript
function add(a, b){
	return a + b; 
}

console.log(add('3', '5')); // 결과는 35, 어떤 에러 메시지도 출력하지 않음


// TypeScript
function add(a: number, b: number){
	return a + b;
}

console.log(add('3', '5')); // 컴파일 에러 메시지 출력

JavaScript로 작성된 코드는 argument가 string이라도 어떤 에러 메시지도 출력하지 않고,

string을 합쳐버린다. 

반면, TypeScript는 parameter의 type이 number이기 때문에, 

argument에 string을 넣은 경우, 컴파일 에러 메시지를 출력한다. 

*컴파일 에러는 무엇일까?

말그대로, 컴파일 시 나타나는 에러이다. 

컴파일은 어떤 언어의 코드를 다른 언어로 바꿔주는 변환 과정이다. 

TypeScript는 JavaScript 환경에서 실행될 수 없다. 

왜냐하면, JavaScript가 실행될 수 있는 브라우저가 TypeScript 코드를 이해하지 못하기 때문이다. 

그래서 TypeScript로 작성된 코드는 JavaScript로 컴파일 되어야 한다. 

즉, TypeScript는 프로그래밍 언어이자, TypeScript를 JavaScript로 바꿔주는 컴파일러이다!

이 포스팅은 아래 링크를 참고하여 작성했습니다.

https://www.youtube.com/watch?v=VJ8rvsw2j5w&t=211s

Authentication(인증)과 Authorization(인가)

누가, 언제, 어떻게 쓰고 있는가를 파악하기 위해 어떤 웹사이트든 Authentication(인증)과 Authorization(인가)가 있다. 

Authentication(인증)

• 유저가 누구인지 확인하는 절차
• 클라이언트가 자신이 주장하는 사용자와 같은 사용자인지를 확인하는 과정
• 방문자가 자신이 회사 건물에 들어갈 수 있는지 확인받는 과정
• ex) 회원가입, 로그인
• 필요 이유: 서비스를 누가 사용하는지 추적이 가능하도록 하기 위해서. 타인에게 사용자의 정보를 보호하기 위해서. 

Authorization(인가)

• 권한 부여
• 클라이언트가 하고자 하는 작업이 해당 클라이언트에게 허가된 작업인지를 확인
• 특정 자원에 대한 접근 권한이 있는지 확인하는 절차
• 유저에 대한 권한을 허락하는 것
• 방문자가 회사 건물에 방문했을 때, 허가된 공간에만 접근 가능

웹 인증(Authentication)

웹에서 인증을 요청하는 유저는 서버에게 두 가지 정보를 제시한다. 

• 아이디 : 나는 '누구'이다. 
• 비밀번호 : 내가 그 유저인 '증거'이다. 

HTTP 요청 방식

서버에 유저 정보를 보내서 사용 허가를 받는다. 

HTTP의 특징은 Request(요청)와 Response(응답)이다.

하지만, 이 방식에는 문제가 있다. 

통신을 서로 주고 받지만, 클라이언트와 서버가 서로 연결되어 있는 것은 아니기 때문에 

각각의 통신은 독립적이다. 

그리고, 한 번 요청과 응답이 완료되면 저장되지 않는 stateless 성질이 있다.

즉, 한 번 요청과 응답이 끝나면 상태 정보를 유지하지 않는다. 

그래서 다른 페이지로 넘어가면 정보가 없으므로, 인증 절차가 필요하다. 

HTTP 요청 인증 방식(쿠키, 세션, 토큰인증기반)

쿠키(Cookie)

• 쿠키는 클라이언트(유저의 컴퓨터)에 저장되는 텍스트 형식의 데이터
• 쿠키는 방문한 웹사이트에서 생성된 파일로, 인터넷 사용정보를 저장
• 쿠키에는 사용자 인증이 유효한 시간을 명시할 수 있음
• 한 번 유효 시간이 정해지면, 브라우저를 끄더라도 인증이 유지됨
• ex) 방문 사이트에서 로그인 시, '아이디와 비밀번호를 저장하시겠습니까?'
• ex) 쇼핑몰의 장바구니 기능

세션(Session)

• 세션은 쿠키를 기반으로 함
• 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리, 세션은 서버에서 관리
• 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지함
• 사용자에 대한 정보를 서버가 저장하기 때문에, 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다. 그래서 동접자 수가 많은 웹사이트의 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다. 

쿠키와 세션의 차이

• 가장 큰 차이는 사용자의 기록 정보가 저장되는 위치
• 쿠키는 서버의 자원을 전혀 사용하지 않고, 세션은 서버의 자원을 사용한다. 
• 세션은 사용자 수만큼 서버 메모리를 차지하기 때문에, 요즘은 이런 문제를 보완한 토큰 기반의 인증 방식(JWT)을 사용하는 추세이다. 

토큰인증기반(JWT, Json Web Token)

• JSON 데이터 구조로 표현한 토큰이다.
• 서버에 정보를 보내고 결과를 JSON 형태 토큰으로 받는다. 

aaaaaa.bbbbbb.cccccc
헤더(header).내용(payload).서명(signature)

[JWT process]

이미지 참조) https://www.vaadata.com/blog/jwt-tokens-and-security-working-principles-and-use-cases/