|
6 | 6 | <span id="token-part-payload" style="color:blue;"><%= token.split(".")[1] %></span><span style="font-weight:bold;font-size:120%;">.</span> |
7 | 7 | <span id="token-part-signature" style="color:green;"><%= token.split(".")[2] %></span> |
8 | 8 | </div> |
9 | | -<br/><br/> |
| 9 | +<br/> |
| 10 | +<p> |
| 11 | +This is a practical example of a JWT |
| 12 | +<br/>Wow, it looks garbage! |
| 13 | +<br/>Sure it does look like garbage, but it is not. In the next few minutes, you’ll see how easy it is to turn this garbage into useful information. |
| 14 | +</p> |
10 | 15 | <h3>Token schema</h3> |
11 | 16 | <p>Did you notice two dots(.) in the token? These dots (.) separate 3 important parts of the token</p> |
12 | 17 |
|
13 | 18 | <b><code>{<span style="color:red;">header</span>}.{<span style="color:blue;">payload</span>}.{<span style="color:green;">signature</span>}</code></b><br/> |
14 | 19 | <ol> |
15 | | - <li><b>Header</b>: Metadata about the cryptography methods e.g. Algorithm, Token type. |
16 | | - <br/>Encoded with base64UrlEncode, can easily be decoded by anyone who has access to token. |
17 | | - <br/><span>Let's <a href="javascript:alert(window.atob(document.getElementById('token-part-header').textContent))">decode header</a> with browser's <code>atob()</code> method</span> |
| 20 | + <li><b>Header</b><code style="color: red; font-size: 80%;margin-left: 12px;">eyJhbGciOiJSU....</code> |
| 21 | + <br/>This part is the metadata about the cryptography methods used for signature(the last part of this token) |
| 22 | + e.g. The Cryptography Algorithm, Token type, etc. |
| 23 | + <p style="font-weight: 300;"> |
| 24 | + <span style="font-weight: 200;opacity: 80%;">What! Where? It is not readable.</span> |
| 25 | + <br/>Hold on! The header is encoded with <code>base64UrlEncode</code>, and can easily be decoded by anyone without any additional information other than the token itself. Let's decode this header with browser's <code>atob()</code> method. |
| 26 | + <br/><br/><button><a href="javascript:alert(window.atob(document.getElementById('token-part-header').textContent))">Click to decode header</a></button> |
| 27 | + <br/>(This will show you the decoded header in plain text) |
| 28 | + |
| 29 | + <br/><br/>👉 Takeaway: The header can be decoded by anyone. It’s not garbage for anyone. |
| 30 | + </p> |
| 31 | + </li> |
| 32 | + <li><b>Payload</b><code style="color: blue; font-size: 80%;margin-left: 12px;">eyJkYXRhIjoiSSB....</code> |
| 33 | + <br/>Actual data we want to exchange via this token e.g. userId |
| 34 | + <p style="font-weight: 300;"> |
| 35 | + This is also encoded with <code>base64UrlEncode</code>. Just like the header, let's decode payload as well with browser’s <code>atob</code> method. |
| 36 | + <br/><br/><button><a href="javascript:alert(window.atob(document.getElementById('token-part-payload').textContent))">Click to decode payload</a></button> |
| 37 | + <br/>This will show you the decoded payload in plain text |
| 38 | + <br/><br/>👉 Takeaway: The payload can be decoded by anyone. It’s not garbage for anyone. |
| 39 | + </p> |
18 | 40 | </li> |
19 | | - <li><b>Payload</b>: Actual data we want to exchange e.g. userId. |
20 | | - <br/>This is also encoded with base64UrlEncode. <span>Let's <a href="javascript:alert(window.atob(document.getElementById('token-part-payload').textContent))">decode payload</a></span> |
| 41 | + <li><b>Signature</b><code style="color: green; font-size: 80%;margin-left: 12px;">RmT_mo6_TjjTiuv....</code> |
| 42 | + <br/>To verify sender or ensure message integrity |
| 43 | + <p style="font-weight: 300;"> |
| 44 | + Can be verified by anyone if they know a secret/publicKey. But changing data(spoofing) is not possible. |
| 45 | + <br/><br/><span style="font-weight: 200;">What do you need to verify a token's integrity?</span> |
| 46 | + <br/>You need something more than just the token. You need to know a public key corresponding to the private-key used during the creation of this token. |
| 47 | + <br/><br/>Because I am the creator of this example token that I just showed you. I used an algorithm called <code>RSA256</code> where I used a pair of public/private keys for this token. |
| 48 | + <br/>Now, I’m sharing the public key with you, now you go ahead and verify JWT integrity with this public key. |
| 49 | + <br/><br/><button><a target="_blank" href="/jwt/verify/<%= token %>">Verify this JWT now</a> </button> |
| 50 | + </p> |
21 | 51 | </li> |
22 | | - <li><b>Signature</b>: To verify sender or ensure message integrity. Can be verified by anyone if they know secret/publicKey. But changing data(spoofing) is not possible.</li> |
23 | 52 | </ol> |
24 | 53 |
|
| 54 | +<br/>Ok, now you understand how does a JWT look like, but... |
| 55 | +<h2>What can JWTs be used for?</h2> |
| 56 | +<p style="font-weight: 300;"> |
| 57 | +JWTs can be used as a digital claim issued by one party, which another party can verify for integrity. |
| 58 | + <ul> |
| 59 | + <li>Typical usage of JWTs are</li> |
| 60 | + <li>To prove whether a user is logged in or not</li> |
| 61 | + <li>To prove whether a user is authorized to perform admin actions or not</li> |
| 62 | + </ul> |
| 63 | + What’s more interesting? |
| 64 | + <strong>In order to verify JWT integrity, the other party(one that verifies) does not need to communicate with the first party(one that created JWT)</strong>. Well, assuming the first party has shared the public key with the other party already. |
| 65 | + <br/>So what if I leverage this to create a system as following |
| 66 | + <ol> |
| 67 | + <li>A computer verifies user identity(e.g. username/password) and issues JWTs to the users. Let’s call it an “identity server”</li> |
| 68 | + <li>Another computer that takes requests for users’ protected resources, let’s call it “application server”. It asks for JWT along with the request. This computer(application server) verifies the JWT and makes sure that the JWT was not tampered with</li> |
| 69 | + <li>And then the above “application server” uses JWT payload data to decide whether to give access to a particular resource or not. Essentially allowing the access to users as “identity server” wanted (remember the identity server created the JWT in step 1, at that time, it had also put in the access related necessary info in the JWT)</li> |
| 70 | + </ol> |
| 71 | + |
| 72 | + This is a typical example of authentication/authorization using JWTs and the interesting thing here is that you separated the work related to identity vs work related to actual user resources. You don’t need to rely on a single central system any more to effectively do this and thus can scale and manage in a better way. |
| 73 | +</p> |
| 74 | + |
| 75 | +Let’s see this system in action |
| 76 | + |
25 | 77 |
|
26 | | -<a target="_blank" href="https://jwt.io/introduction/">Read more..</a><br/> |
| 78 | +<!-- <a target="_blank" href="https://jwt.io/introduction/">Read more..</a><br/> --> |
27 | 79 |
|
28 | 80 | <br/><br/> |
29 | | -<a href="/jwt/verify/<%= token %>">Next: Verify JWT.</a><br/> |
| 81 | +<a href="/jwt/form">Next: Create a JWT</a><br/> |
30 | 82 |
|
31 | 83 | <br/><br/><br/><br/><br/><br/> |
32 | 84 | <footer> |
|
0 commit comments