[네트워크] 토큰 기반 인증과 JWT

토큰 기반 인증

모던 웹서비스에서 많이 사용되고 있으며 토큰을 사용해 유저들의 인증작업을 처리하는 것

 

장점

Stateless 서버

상태를 유지 않는 서버로 상태 정보를 저장하지 않는다. 그러므로 서버는 클라이언트측에서 들어오는 요청만으로 작업을 처리한다. 이렇게 상태 정보가 없는 경우 클라이언트와 서버의 연결고리가 없어 서버의 확장성이 높아진다

 

모바일 어플리케이션

모바일 어플리케이션에 사용할 안전한 API를 만들기 위해서는 쿠키 같은 인증시스템은 이상적이지 않다. 토큰 기반 인증을 도입해 더욱 간단하게 해결할 수 있다.

 

인증 정보 전달

다른 웹서비스에서도 로그인하는 것이 가능해진다. 대표적으로 OAuth가 있고 페이스북/구글같은 소셜 계정을 이용하는 것을 말한다.

 

보안

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

 

---

서버 기반 인증

서버측에서 유저들의 정보를 기억해 인증작업을 처리하는 것이다. 메모리/디스크/데이터베이스시스템을 사용했다.

 

문제점

세션

유저의 인증을 위해 서버는 세션에 정보를 저장한다. 즉, 메모리 혹은 데이터베이스에 저장되는데 유저의 수가 늘어나면 과부하로 인한 문제가 발생한다.

 

확장성

세션을 사용하면 서버를 확장하는 것이 어려워진다. 여기서의 서버 확장은 scale-out방식(여러 개의 프로세스 혹은 여러 개의 서버 컴퓨터)를 의미하는데, 세션을 사용하면서 분산 시스템을 설계하는 것은 과정이 매우 복잡해진다.

 

CORS

웹 앱에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

 

---

토큰 기반 인증의 작동원리

토큰 기반 시스템은 stateless로 상태 정보를 유지하지 않는다. 이로 인해 서버인증에서 상태를 저장함으로써 나타난 문제를 모두 해소할 수 있다.

 

1. 유저가 아이디와 비밀번호로 로그인 시도

2. 서버측에서 해당 계정 정보를 검증

3. 계정정보와 입력정보가 동일하다면 서버측에서 유저에게 signed 토큰 발급

4. 클라이언트 측은 토큰을 저장해두고 서버에 요청할 때마다 해당 토큰을 함께 서버로 전달

5. 서버는 토큰을 검증하고 요청에 응답

 

 

장점

무상태와 확장성

토큰 기반 인증 시스템의 가장 중요한 속성이면서 장점이다. 토큰을 클라이언트 측에 저장하므로 서버 입장에서는 stateless이며 이로 인해 서버의 확장성이 증대된다. 만약 서버측에 저장이 되어 있는데 서버가 여러 대여서 요청을 분산한다면 모든 서버가 상태를 저장하고 있어야 한다. 토큰을 사용함으로써 이러한 문제점을 해결할 수 있다.

 

보안

클라이언트가 서버에 요청할 때 쿠키를 전달하지 않으므로 쿠키를 사용할 때 발생하는 취약점이 사라진다. 하지만, 토큰으로 인한 취약점도 여전히 존재한다.

 

Extensibility(확장성)

서버의 확장이 아닌 로그인 정보가 사용되는 분야를 확장하는 것을 의미한다. 토큰을 사용하여 다른 서비스에서도 권한을 공유할 수 있게 되는 것이다. (구글 계정을 사용해 여러 사이트에 연동하여 로그인할 수 있는 것)

 

여러 플랫폼 및 도메인

CORS문제의 해결을 의미한다. 여러 디바이스의 호환, 다양한 종류의 서비스를 제공할 때 토큰을 사용한다면 다양한 요청을 정상적으로 처리할 수 있다.

 

---

JWT(JSON Web Token)

웹표준으로 두 개체에서 JSON객체를 사용해 가볍고 자가수용적인 방식으로 정보를 안정성 있게 전달해준다. 디지털 서명이 되어 있으므로 신뢰할 수 있으며, HMAC, RSA, ECDSA 등의 암호화 방식을 사용한다.

 

장점

다양한 프로그래밍 언어 지원

C, Java, Python, C++, R, C#, PHP, JavaScript, Ruby, Go, Swift 등 주류 프로그래밍 언어에서 모두 지원

 

자가수용적(self-contained)

모든 정보를 자체적으로 지니고 있다. JWT시스템에서 발급된 토큰은 토큰에 대한 기본 정보, 전달할 정보, 토큰이 검증됐다는 걸 증명하는 signature를 포함한다.

 

쉽게 전달 가능

자가수용적이므로 두 개체 사이에서 손쉽게 전달될 수 있다. 웹 서버의 경우 http 헤더에 넣어 전달 할수 있도 url의 파라미터로도 전달할 수 있다.

 

활용

회원인증과 안전한 정보 공유에 사용됨

회원인증

1. 유저 로그인 시도

2. 서버는 유저의 정보에 기반한 토큰 발급 후 유저에게 전달

3. 유저는 요청 시마다 jwt를 포함해 전달

4. 서버는 요청시마다 토큰을 검증하고 유저가 요청한 작업에 권한이 있는지 확인 후 작업

 

서버는 유저의 세션을 유지할 필요가 없고 로그인 여부를 관리할 필요 없음 토큰만 확인하면 됨 서버 자원 절약

 

정보 교환

정보가 sign되어 있으므로 정보를 보낸이가 바뀌진 않았는지, 정보가 조작되지 않았는지 검증 가능

 

---

JWT 구조

.(온점)으로 구분된 세 가지 파트(Header, Payload, Signature)로 이루어져 있다.

XXXXX.YYYYY.ZZZZZ

 

헤더(Header)

일반적으로 토큰의 유형과 사용할 signing 알고리즘으로 이루어진다. HMAC, SHA256, RSA 등을 사용한다.

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

그 후, 이 JSON은 Base64Url로 인코딩하여 JWT의 첫 부분으로 사용한다.

 

페이로드(Payload)

토큰의 두번째 파트로 클레임(claim)들을 담고 있다. 클레임은 개체(주로 사용자)에 대한 설명과 추가 정보를 담고 있다. 세 가지 종류의 클레임이 있다.(registered, public, private)

• Registered claims : 미리 정의된 클레임의 세트로 권장사항일 뿐, 필수 요소는 아니다. 서비스를 위해서가 아닌 토큰 자체에 대한 정보들을 담고 있다. 토큰 발행자(iss), 만료 시간(exp), 토큰 제목(sub), 토큰 대상자(aud) 등이 있다.
• Public claims : JWT를 사용하는 사람들이 정의한다. 충돌 방지를 위해 클레임 이름을 URI 형식으로 하거나 IANA JSON Web Token Registry에 정의해야 한다.
• Private claims : 당사자 간 정보를 공유하기 위해 생성된 사용자 지정 클레임이다.

{
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true
}

이 역시 Base64Url로 인코딩 되어 JWT의 두번째 파트로 쓰인다.

 

서명(Signature)

인코딩된 헤더와 인코딩된 페이로드, secret(비밀 키), 헤더에 지정한 알고리즘을 사용해 서명한다.

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

서명은 메시지가 변경되지 않았음을 증명하는데 사용되며, 개인 키로 서명된 토큰의 경우 JWT로 유저를 검증할 수 있다.

 

세 파트를 모두 합쳐 JWT를 만들어낼 수 있다.

 

 

 

https://velopert.com/2389

[JWT] JSON Web Token 소개 및 구조 | VELOPERT.LOG

https://velopert.com/2389

[JWT] JSON Web Token 소개 및 구조 | VELOPERT.LOG

https://jwt.io/introduction

JWT.IO