<div id="readability-page-1" class="page"><div>
                  <p><a href="/m/category/%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D/%EA%B8%B0%ED%83%80"><span>프로그래밍/기타</span></a></p><h3>[JWT] JWT(Json Web Token)에 대해서 자세히 알아봅시다  - 이론편</h3>
                </div><p><cite>사바라다</cite>
                  <span> 2023. 2. 19. 02:03</span>
                </p><div>
                                <figure data-ke-mobilestyle="widthOrigin" data-filename="jwt_icon.png" data-origin-width="600" data-origin-height="600">
    <span data-url="https://blog.kakaocdn.net/dn/cqbtEQ/btrZISJO4rM/psTAeZ2SeJr4mw2z80gt00/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/cqbtEQ/btrZISJO4rM/psTAeZ2SeJr4mw2z80gt00/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" width="193" height="193" data-filename="jwt_icon.png" data-origin-width="600" data-origin-height="600">
    </span>
    
</figure>
<p data-ke-size="size16">안녕하세요. 오늘은 JWT와 그 기본적인 스펙에 대해 자세히 알아보는 시간을 가져보도록 하겠습니다.</p>
<p data-ke-size="size16">저의 옛날 포스팅에 보면 JWT에 대해서 간단히 설멍했던 글이 있습니다.</p>
<p data-ke-size="size16"><a href="https://sabarada.tistory.com/35">[REST API] REST API의 Security With JWT</a></p>
<p data-ke-size="size16">하지만 너무 단순한 개념적인 부분만 설명드렸기 때문에 이번 기회로 제대로 정리해보고자 합니다.</p>
<h2 data-ke-size="size26">JWT 란 무엇인가 ?</h2>
<p data-ke-size="size16">JWT는 Json Web Token의 약자로써 서로다른 기기에 데이터를 전달할 때 사용하는 방법중 하나입니다.</p>
<p data-ke-size="size16"><b>구성은 기본적으로 <a href="https://ko.wikipedia.org/wiki/%EB%B2%A0%EC%9D%B4%EC%8A%A464">Base64포맷</a>이며 Header와 Body(claim 이라고 부르기도 합니다) 그리고 Signature 부분으로 나뉘어집니다. 실제로 JWT는 아래처럼 생겼습니다.</b> <code>.</code>을 기준으로 slice하면 첫번째 부분부터 Header, Body, Signature 입니다. 각각에 대한 자세한 이야기는 아래에서 진행하도록 하겠습니다.</p>
<pre><code>eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJLYXJvbCJ9.8Ql4P8CirU_rEbhJKSwimrQ9_7MsMhffycxy02J_h9I</code></pre>
<p data-ke-size="size16">JWT는 header와 body에 사인(Sign)이 가능하고 추가로 암호화(aka. Encrypted JWT)도 가능합니다. <b>기본적으로 Sign이 들어가기 때문에 header 또는 body를 수정하게 되면 Signature가 맞지 않게 됩니다. 따라서 데이터의 변조 방지가 가능합니다. 그리고 만료기간을 설정할 수 있습니다. 이러한 점 때문에 주로 유저가 로그인 후 정상적인 접근을 증명하는 AccessToken으로 사용할 수 있고 사용합니다.</b></p>
<h2 data-ke-size="size26">JWT의 형태와 예시</h2>
<p data-ke-size="size16">아래는 JWT의 간단한 형태입니다. 이것은 Base64로 인코딩되어있기 때문에 Readable하진 않습니다. 하지만 암호화와는 다르기 때문에 이를 발급받은 Client가 원한다면 값을 디코딩 해볼 수 있습니다.</p>
<pre><code>eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJLYXJvbCJ9.8Ql4P8CirU_rEbhJKSwimrQ9_7MsMhffycxy02J_h9I</code></pre>
<p data-ke-size="size16">JWT는 위에서 설명했지만 <code>.</code>를 기준으로 첫번째부터 Header, Body, Signature로 나뉘어집니다. 이를 각각 디코딩하게 되면 Json 포맷을 가지고 있다는 것을 알수 있습니다.</p>
<h3 data-ke-size="size23">Header</h3>
<p data-ke-size="size16">JWT의 Header는 JWT의 <a href="https://ko.wikipedia.org/wiki/%EB%A9%94%ED%83%80%EB%8D%B0%EC%9D%B4%ED%84%B0">metadata</a>들을 나타냅니다. 여기에는 Sign에 사용된 Algorithms, format, 그리고 ContentType 등의 정보가 들어갈 수 있습니다.</p>
<p data-ke-size="size16">위 예제에서 Header는 <code>eyJhbGciOiJIUzI1NiJ9</code> 입니다. 이를 base64 디코딩을 진행하면 아래와 같은 정보를 얻을 수 있습니다. alg는 JWT에 Signed를 진행했을 때인 JWS의 표준 헤더중 하나입니다. <a href="https://www.rfc-editor.org/rfc/rfc7515#section-4.1.1" target="_blank" rel="noopener">RFC-7515</a>문서 보시면 JWT에 사용된 Signiture 알고리즘의 종류라는 것을 알 수 있습니다.</p>
<pre><code>{"alg":"HS256"}</code></pre>
<h3 data-ke-size="size23">Payload</h3>
<p data-ke-size="size16"><b>Payload는 JWT의 Body에 해당</b>되는 부분입니다. Payload의 단위는 Claims로써 사실상 실제 데이터는 Claims라는 단위로 저장됩니다면 json의 필드라고 생각해주시면 될것 같습니다. 이러한 Claims에는 JWT 생성자가 원하는 정보들을 자유롭게 담을 수 있습니다. 이 역시 Json 형식을 가지고 있기 때문에 단일 필드도 가능하지만 Object와 같은 complexible한 필드 역시 추가가 가능합니다. ex) <code>{"user" : {...}}</code></p>
<p data-ke-size="size16">위 예제에서 Claim은 <code>eyJzdWIiOiJLYXJvbCJ9</code>입니다. 이를 한번 Base64 디코딩을 진행해보겠습니다. <code>iss</code>라는 필드가 있는 것을 확인할 수 있습니다. iss는 JWT의 표준인 RFC-7519에 명시되어있는 Registered Fields 중 하나입니다. 해당 필드의 풀네임은 issuer이고 해당 JWT의 발급자를 나타냅니다. 아래에서 발급자는 Karol 이라는 사실을 Client는 Decoding을 통해서 알 수 있습니다.</p>
<pre><code>{"iss":"Karol"}</code></pre>
<h3 data-ke-size="size23">Signature</h3>
<p data-ke-size="size16"><b>위에서 확인했던 Header와 Claims는 모두 Base64로 인코딩 되어있으며 암호화는 되어있지 않는 것</b>을 알 수 있습니다. 그렇다면 이것은 공격자가 값을 바꿀 수 있다는 뜻입니다. <b>이 경우 서버에서는 JWT 내부의 값이 변도 되었다는 사실을 어떻게 알 수 있을까요 ? 바로 해당 Signature를 통해서 알 수 있습니다.</b> Signature는 아래와 같은 방식으로 만들어지게 됩니다.</p>
<pre><code>String concatenated = encodedHeader + '.' + encodedClaims
Key key = getMySecretKey()
byte[] signature = hmacSha256( concatenated, key )</code></pre>
<p data-ke-size="size16">Base64로 인코딩한 Header와 Claims를 먼저 만든 후 이를 Key를 통해서 Sign하는 방식입니다. 따라서 Client에서 Header 또는 Claims의 값을 변경한다면 이는 signature의 불일치로 인해서 서버에서 받아들여지지 않습니다.</p>
<h2 data-ke-size="size26">JWT의 Registered Fields</h2>
<p data-ke-size="size16">JWT 스펙인 RFC-7515와 Signed JWT(JWS) 스펙인 RFC-7519를 보면 표준으로 사용할 수 있는 Registered Fields를 나열하고 있습니다. 각각에 대해서 간단히 언급하는 수준으로 살펴보고 가도록 하겠습니다. <b>해당 필드들은 필수는 아니고 모두 선택적(Optional)입니다.</b>&nbsp;하지만 커스텀을 하더라도 표준 필드를 알면 더 좋은 JWT 설계를 할 수 있기 때문에 알고있는것은 중요한 덕목중 하나 일 것입니다.</p>
<ul data-ke-list-type="disc">
<li>iss (Issuer) : JWT를 발급한 주체</li>
<li>sub (Subject) : JWT의 발급의 목적(주제)</li>
<li>aud (Audience) : JWT 발급받은 수신자
<ul data-ke-list-type="disc">
<li>해당 값으로 식별이 가능해야합니다.</li>
</ul>
</li>
<li>exp (Expiration Time) : JWT 만료시간</li>
<li>nbf (Not Before) : JWT 활성화 시간</li>
<li>iat (Issued At) : JWT 발급 시간</li>
<li>jti (JWT ID) : JWT 발급의 Unique ID</li>
</ul>
<p data-ke-size="size16"><b>해당 claims 중 exp, nbf, iat는 모두 NumericDate 타입이며 이는 1636027948와 같이 seconds(milliseconds 아님)로 나타냅니다.</b></p>
<h2 data-ke-size="size26">마무리</h2>
<p data-ke-size="size16">오늘은 이렇게 JWT에 대해서 자세히 알아보는 시간을 가져보았습니다.</p>
<p data-ke-size="size16">다음시간에는 java 라이브러리인 jjwt를 이용하여 jwt를 생성하고 검증하는 실습 예제를 진행해보겠습니다.</p>
<p data-ke-size="size16">감사합니다.</p>
<h2 data-ke-size="size26">참조</h2>
<p data-ke-size="size16">[1] <a href="https://www.rfc-editor.org/rfc/rfc7519">https://www.rfc-editor.org/rfc/rfc7519</a></p>
<p data-ke-size="size16">[2] <a href="https://github.com/jwtk/jjwt">https://github.com/jwtk/jjwt</a></p>
<p data-ke-size="size16">[3] <a href="https://jwt.io/introduction">https://jwt.io/introduction</a></p>
<p data-ke-size="size16">[4] <a href="https://www.rfc-editor.org/rfc/rfc7519#section-4.1">https://www.rfc-editor.org/rfc/rfc7519#section-4.1</a></p>
<p data-ke-size="size16">[5] <a href="https://www.rfc-editor.org/rfc/rfc7515#section-4.1.1">https://www.rfc-editor.org/rfc/rfc7515#section-4.1.1</a></p>
            
            
                </div></div>

사바라다는 차곡차곡

안녕하세요. 오늘은 JWT와 그 기본적인 스펙에 대해 자세히 알아보는 시간을 가져보도록 하겠습니다.
저의 옛날 포스팅에 보면 JWT에 대해서 간단히 설멍했던 글이 있습니다.
[REST API] REST API의 Security With JWT
하지만 너무 단순한 개념적인 부분만 설명드렸기 때문에 이번 기회로 제대로 정리해보고자 합니다.
JWT 란 무엇인가 ?
JWT는 Json Web Token의 약자로써 서로다른 기기에 데이터를 전달할 때 사용하는 방법중 하나입니다.
구성은 기본적으로 Base64포맷이며 Header와 Body(claim 이라고 부르기도 합니다) 그리고 Signature 부분으로 나뉘어집니다. 실제로 JWT는 아래처럼 생겼습니다. .을 기준으로 slice하면 첫번째 부분부터 Header, Body, Signature 입니다. 각각에 대한 자세한 이야기는 아래에서 진행하도록 하겠습니다.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJLYXJvbCJ9.8Ql4P8CirU_rEbhJKSwimrQ9_7MsMhffycxy02J_h9I
JWT는 header와 body에 사인(Sign)이 가능하고 추가로 암호화(aka. Encrypted JWT)도 가능합니다. 기본적으로 Sign이 들어가기 때문에 header 또는 body를 수정하게 되면 Signature가 맞지 않게 됩니다. 따라서 데이터의 변조 방지가 가능합니다. 그리고 만료기간을 설정할 수 있습니다. 이러한 점 때문에 주로 유저가 로그인 후 정상적인 접근을 증명하는 AccessToken으로 사용할 수 있고 사용합니다.
JWT의 형태와 예시
아래는 JWT의 간단한 형태입니다. 이것은 Base64로 인코딩되어있기 때문에 Readable하진 않습니다. 하지만 암호화와는 다르기 때문에 이를 발급받은 Client가 원한다면 값을 디코딩 해볼 수 있습니다.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJLYXJvbCJ9.8Ql4P8CirU_rEbhJKSwimrQ9_7MsMhffycxy02J_h9I
JWT는 위에서 설명했지만 .를 기준으로 첫번째부터 Header, Body, Signature로 나뉘어집니다. 이를 각각 디코딩하게 되면 Json 포맷을 가지고 있다는 것을 알수 있습니다.
Header
JWT의 Header는 JWT의 metadata들을 나타냅니다. 여기에는 Sign에 사용된 Algorithms, format, 그리고 ContentType 등의 정보가 들어갈 수 있습니다.
위 예제에서 Header는 eyJhbGciOiJIUzI1NiJ9 입니다. 이를 base64 디코딩을 진행하면 아래와 같은 정보를 얻을 수 있습니다. alg는 JWT에 Signed를 진행했을 때인 JWS의 표준 헤더중 하나입니다. RFC-7515문서 보시면 JWT에 사용된 Signiture 알고리즘의 종류라는 것을 알 수 있습니다.
{"alg":"HS256"}
Payload
Payload는 JWT의 Body에 해당되는 부분입니다. Payload의 단위는 Claims로써 사실상 실제 데이터는 Claims라는 단위로 저장됩니다면 json의 필드라고 생각해주시면 될것 같습니다. 이러한 Claims에는 JWT 생성자가 원하는 정보들을 자유롭게 담을 수 있습니다. 이 역시 Json 형식을 가지고 있기 때문에 단일 필드도 가능하지만 Object와 같은 complexible한 필드 역시 추가가 가능합니다. ex) {"user" : {...}}
위 예제에서 Claim은 eyJzdWIiOiJLYXJvbCJ9입니다. 이를 한번 Base64 디코딩을 진행해보겠습니다. iss라는 필드가 있는 것을 확인할 수 있습니다. iss는 JWT의 표준인 RFC-7519에 명시되어있는 Registered Fields 중 하나입니다. 해당 필드의 풀네임은 issuer이고 해당 JWT의 발급자를 나타냅니다. 아래에서 발급자는 Karol 이라는 사실을 Client는 Decoding을 통해서 알 수 있습니다.
{"iss":"Karol"}
Signature
위에서 확인했던 Header와 Claims는 모두 Base64로 인코딩 되어있으며 암호화는 되어있지 않는 것을 알 수 있습니다. 그렇다면 이것은 공격자가 값을 바꿀 수 있다는 뜻입니다. 이 경우 서버에서는 JWT 내부의 값이 변도 되었다는 사실을 어떻게 알 수 있을까요 ? 바로 해당 Signature를 통해서 알 수 있습니다. Signature는 아래와 같은 방식으로 만들어지게 됩니다.
String concatenated = encodedHeader + '.' + encodedClaims
Key key = getMySecretKey()
byte[] signature = hmacSha256( concatenated, key )
Base64로 인코딩한 Header와 Claims를 먼저 만든 후 이를 Key를 통해서 Sign하는 방식입니다. 따라서 Client에서 Header 또는 Claims의 값을 변경한다면 이는 signature의 불일치로 인해서 서버에서 받아들여지지 않습니다.
JWT의 Registered Fields
JWT 스펙인 RFC-7515와 Signed JWT(JWS) 스펙인 RFC-7519를 보면 표준으로 사용할 수 있는 Registered Fields를 나열하고 있습니다. 각각에 대해서 간단히 언급하는 수준으로 살펴보고 가도록 하겠습니다. 해당 필드들은 필수는 아니고 모두 선택적(Optional)입니다. 하지만 커스텀을 하더라도 표준 필드를 알면 더 좋은 JWT 설계를 할 수 있기 때문에 알고있는것은 중요한 덕목중 하나 일 것입니다.
iss (Issuer) : JWT를 발급한 주체
sub (Subject) : JWT의 발급의 목적(주제)
aud (Audience) : JWT 발급받은 수신자
해당 값으로 식별이 가능해야합니다.
exp (Expiration Time) : JWT 만료시간
nbf (Not Before) : JWT 활성화 시간
iat (Issued At) : JWT 발급 시간
jti (JWT ID) : JWT 발급의 Unique ID
해당 claims 중 exp, nbf, iat는 모두 NumericDate 타입이며 이는 1636027948와 같이 seconds(milliseconds 아님)로 나타냅니다.
마무리
오늘은 이렇게 JWT에 대해서 자세히 알아보는 시간을 가져보았습니다.
다음시간에는 java 라이브러리인 jjwt를 이용하여 jwt를 생성하고 검증하는 실습 예제를 진행해보겠습니다.
감사합니다.
참조
[1] https://www.rfc-editor.org/rfc/rfc7519
[2] https://github.com/jwtk/jjwt
[3] https://jwt.io/introduction
[4] https://www.rfc-editor.org/rfc/rfc7519#section-4.1
[5] https://www.rfc-editor.org/rfc/rfc7515#section-4.1.1

[JWT] JWT(Json Web Token)에 대해서 자세히 알아봅시다 - 이론편

댓글