JWT ( JSON Web Token ) 이란?

마이크로서비스를 위한 JWS

JWT 는 JSON Web Token의 약자로 전자 서명 된 URL-safe (URL로 이용할 수있는 문자 만 구성된)의 JSON입니다.
전자 서명은 JSON 의 변조를 체크 할 수 있게되어 있습니다.
JWT는 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준 입니다.
JWT는 서버와 클라이언트 간 정보를 주고 받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증합니다.
이때 사용되는 JSON 데이터는 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 만듭니다.
JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있습니다.

클라우드에 최적화된 APM 1개월 무료 사용

JWT 와 관련된 표준인 JWS ( JSON Web Signature) 와 JWE ( JSON Web Encryption)

JWT와 관련된 표준으로는 JSON Web Signature (JWS)는 JSON 데이터 구조를 사용하는 서명 표준으로 RFC7515이며, JSON Web Encryption (JWE)는 JSON 데이터 구조를 사용하는 암호화 방법으로 RFC7516 표준입니다.

JWS (JSON Web Signature)은 간단히 말하면 “JSON으로 전자 서명을하여 URL-safe 문자열로 표현한 것”입니다. 
JWE (JSON Web Encryption)는 “JSON을 암호화하여 URL-safe 문자열로 표현한 것” 입니다.
서명은 서명 할 때 사용한 키를 사용하여 JSON이 손상되지 않았는지 확인 할 수 있도록하는 것입니다. 
URL Safe는 말 그대로 URL에 포함 할 수없는 문자를 포함하지 않는 것입니다.

JWT 토큰 구성

Source : Cookies vs. Tokens: The Definitive Guide –
https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide

JWT는 세 파트로 나누어지며, 각 파트는 점로 구분하여 xxxxx.yyyyy.zzzzz 이런식으로 표현됩니다. 순서대로 헤더 (Header), 페이로드 (Payload), 서명 (Sinature)로 구성합니다.
 Base64 인코딩의 경우 “+”, “/”, “=”이 포함되지만 JWT는 URI에서 파라미터로 사용할 수 있도록 URL-Safe 한  Base64url 인코딩을 사용합니다.

Header는 토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다. 첫째는 토큰의 유형 (JWT)을 나타내고, 두 번째는 HMAC, SHA256 또는 RSA와 같은 해시 알고리즘을 나타내는 부분입니다.
Payload는 토큰에 담을 클레임(claim) 정보를 포함하고 있습니다. Payload 에 담는 정보의 한 ‘조각’ 을 클레임이라고 부르고, 이는 name / value 의 한 쌍으로 이뤄져있습니다. 토큰에는 여러개의 클레임 들을 넣을 수 있습니다.
클레임의 정보는 등록된 (registered) 클레임, 공개 (public) 클레임, 비공개 (private) 클레임으로 세 종류가 있습니다.
마지막으로 Signature는 secret key를 포함하여 암호화되어 있습니다.

JWT Process

Microservice With OAuth

기존의 토큰 방식 인증은 다이어그램에 표시된 것처럼 토큰은 이후의 모든 서비스 호출에 사용됩니다.
서비스를 받기 위해서는 토큰의 유효성을 확인하여 세부 정보를 쿼리해야합니다.
참조에 의한 호출(By Reference) 형태로 모든 서비스는 항상 상호 작용할 때 다시 접속해야합니다.

Microservice With JWT

JWT 와 같이 값에 의한 호출이 가능한 토큰이 필요합니다.
토큰이 필요한 모든 정보를 포함하고 있어 참조(적어도 인증 및 권한 부여를 위해)가 필요없기 때문에 마이크로서비스 자체에서 유효성을 검증 합니다.
이것이 JWT ( JSON Web Token )의 목적입니다!

JWT Process
1. 사용자가 id와 password를 입력하여 로그인을 시도합니다.
2. 서버는 요청을 확인하고 secret key를 통해 Access token을 발급합니다.
3. JWT 토큰을 클라이언트에 전달 합니다.
4. 클라이언트에서 API 을 요청할때  클라이언트가 Authorization header에 Access token을 담아서 보냅니다.
5. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환합니다.
6. 클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰기반 인증 메커니즘을 제공합니다.
인증이 필요한 경로에 접근할 때 서버 측은 Authorization 헤더에 유효한 JWT 또는 존재하는지 확인한다.
JWT에는 필요한 모든 정보를 토큰에 포함하기 때문에 데이터베이스과 같은 서버와의 커뮤니케이션 오버 헤드를 최소화 할 수 있습니다.
Cross-Origin Resource Sharing (CORS)는 쿠키를 사용하지 않기 때문에 JWT를 채용 한 인증 메커니즘은 두 도메인에서 API를 제공하더라도 문제가 발생하지 않습니다.
일반적으로 JWT 토큰 기반의 인증 시스템은 위와 같은 프로세스로 이루어집니다.
처음 사용자를 등록할 때 Access token과 Refresh token이 모두 발급되어야 합니다.

JWT 장점과 단점

JWT 장점

JWT 의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다는 것입니다.
분산 마이크로 서비스 환경에서 중앙 집중식 인증 서버와 데이터베이스에 의존하지 않는 쉬운 인증 및 인가 방법을 제공합니다.
개별 마이크로 서비스에는 토큰 검증과 검증에 필요한 비밀 키를 처리하기위한 미들웨어가 필요합니다. 검증은 서명 및 클레임과 같은 몇 가지 매개 변수를 검사하는 것과 토큰이 만료되는 경우로 구성됩니다.
토큰이 올바르게 서명되었는지 확인하는 것은 CPU 사이클을 필요로하며 IO 또는 네트워크 액세스가 필요하지 않으며 최신 웹 서버 하드웨어에서 확장하기가 쉽습니다.

JSON 웹 토큰의 사용을 권장하는 몇 가지 이유는 다음과 같다.

  • URL  파라미터와 헤더로 사용
  • 수평 스케일이 용이
  • 디버깅 및 관리가 용이
  • 트래픽 대한 부담이 낮음
  • REST 서비스로 제공 가능
  • 내장된 만료
  • 독립적인 JWT

JWT 단점

  • 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없습니다.
  • 더 많은 필드가 추가되면 토큰이 커질 수 있습니다.
  • 비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있습니다.

다음과 같은 상황에서 JWT 가 유용하게 사용 될 수 있습니다.

  • 회원 인증: JWT 를 사용하는 가장 흔한 시나리오 입니다. 사용자가 로그인을 하면, 서버는 사용자의 정보를 기반으로한 토큰을 발급합니다.
    그 후, 사용자가 서버에 요청을 할 때 마다 JWT를 포함하여 전달합니다. 서버는 클라이언트에서 요청을 받을때 마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 사용자가 요청한 작업에 권한이 있는지 확인하여 작업을 처리합니다.
    서버에서는 사용자에 대한 세션을 유지 할 필요가 없습니다. 즉 사용자가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 사용자가 요청을 했을때 토큰만 확인하면 되므로 세션 관리가 필요 없어서 서버 자원과 비용을 절감할 수 있습니다.
  • 정보 교류: JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법입니다. 그 이유는, 정보가 서명이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지, 또 정보가 도중에 조작되지는 않았는지 검증할 수 있습니다.
마이크로서비스와 JWT

거대하고 복잡한 단일 애플리케이션 개발에서 서비스를 작은 단위로 분할하여 민첩한 개발을 할 수 있는 마이크로 서비스가 주목 받고 있습니다.하지만 소프트웨어에서 보안은 항상 어려운 문제입니다.
마이크로서비스 아키텍처가 발전함에 따라 각각의 API 서버들은 API 클라이언트에 대한 Authentication (인증)과 Authorization (인가/권한부여)를 위한 매커니즘이 필요합니다.
JSON Web Token (JWT)는 마이크로 서비스의 인증, 인가에 사용할 수 있는 서명된 JSON 입니다.
토큰을 사용하면 세션을 통한 방식과 달리 서버측 부하를 낮출 수 있고 능률적인 접근 권한 관리를 할 수 있으며 분산/클라우드 기반 인프라스트럭처에 더 잘 대응할 수 있습니다.

JWT (JSON Web Token) – 마이크로서비스를 위한 인증과 인가

자세히 보기 ...

JBoss EAP7에 포함된 Red Hat SSO 는 무엇?

  • Red Hat SSO (Keycloak )은 Web에서 SSO를 구현하기 위한 오픈소스
  • SAML 2.0 뿐만 아니라 REST/JSON 기반의 OpenID Connect 지원
자료 다운로드
Red Hat SSO
Red Hat SSO Red Hat SSO Red Hat SSO Red Hat SSO Red Hat SSO Red Hat SSO Red Hat SSO

References & Related Links

쿠버네티스 개념 뽀개기와 데모 그리고 무료 체험 신청

클라우드 네이티브 세미나 비대면 ( 쿠버네티스 )

최근 코로나19로 인한 비대면 솔루션의 수요가 늘면서, 클라우드 네이티브 앱 개발과 클라우드 네이티브 컴퓨팅 환경에 대한 요구사항들이 급증하고 있습니다.
그러나 COVID-19라는 재난으로 인해 디지털 트랜스포메이션, 클라우드 전환 등은 반강제적으로 그리고 빠르게 산업에 침투하고 있습니다.
고객 직접 대면이 어려운 지금, 비대면으로 고객들이 PoC(Proof of Concept)를 체험할 수 있도록 그 활용 가이드를 제안해드립니다.

클라우드 네이티브 비대면 워크샵 신청

JBoss EAP 제품소개 자료

  • 클라우드/컨테이너 환경에 최적화
  • 마이크로서비스 아키텍처 지원
  • 가볍고 빠른 미들웨어
  • Wildfly 기반
자료 다운로드

오픈소스WAS 전환 체크리스트

  • 마이그레이션의 난이도와 투입 리소스를 예측하기 위한 사전 진단 시트
  • 해당 업무의 개발자와 운영자를 대상으로 인터뷰를 진행
  • 기존 시스템의 운영 이슈나 개선점 확인
체크리스트 다운로드
JBoss 마이그레이션 도구

UNIX-to-Linux (U2L) 개요

  • 저비용 고효율 IT 시스템 구축

    • 전세계 Unix 시장점유율은 계속 감소하는데 반해 리눅스는 증가하고 있는 추세임
    • Unix 시스템을 비용효율적인 X86 서버로 대체함으로서, 시스템 구축 비용 및 운영 비용 절감과 유연성 확보

  • IT 환경의 유연성과 기술혁신 토대 마련

    • 신기술 수용, 유연성, 비용 효율화, 유지보수 효율성 확보
    • x86/리눅스 기반의 인프라 혁신이 주류
    • 최근 SW의 개발환경이 대부분 리눅스 플랫폼임

  • 클라우드 레디 시스템 구축

    • 클라우드 인프라 기반 플랫폼은 x86/리눅스 서버가 주를 이룸
    • x86 서버는 오픈 클라우드 환경 전환이 용이하나, Unix서버는 벤더 종속적임
Unix 에서 Linux 전환
거침없이 배우는 JBoss – 10점
전준식 엮음/지&선(지앤선)