この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。RFC 7519とMicrosoft identity platformの現行資料、既存Daily-Code-Samplesを確認し、実アクセストークンを使わずJWTの構造だけを観察します。
検証ステータス：📘 公式情報確認済み・PowerShell実行未確認
JWTは「読める部分がある」ことと「信頼できるtokenである」ことが別です。実際のMicrosoft Entraアクセストークンを貼り付けず、完全なダミー header.payload.signature を作ってBase64URL decodeだけを体験すると、この違いが分かります。
まず動かす
実トークンは使いません。教育用の未署名データだけを作ります。
function To-Base64Url([string]$Text) {
$bytes = [Text.Encoding]::UTF8.GetBytes($Text)
[Convert]::ToBase64String($bytes).TrimEnd('=').Replace('+','-').Replace('/','_')
}
$header = '{"alg":"none","typ":"JWT"}'
$payload = '{"sub":"demo-user","role":"reader"}'
$token = "$(To-Base64Url $header).$(To-Base64Url $payload)."
Write-Host '[DUMMY]'
Write-Host $token
Write-Host '[SUCCESS] 3つの部分を持つ教育用データを作成しました'
JWTの標準はRFC 7519です。
ここを見る
. で分けると3つの部分になります。
header.payload.signature
今回の末尾は空です。alg=none の教育用未署名データだからで、認証用途には使えません。
flowchart LR
H[header JSON] --> E1[Base64URL]
P[payload JSON] --> E2[Base64URL]
E1 --> J[header.payload.signature]
E2 --> J
J --> D[decodeして内容を読む]
D --> N[署名検証とは別]
decodeしてみる
Base64URLは通常のBase64と文字・paddingの扱いが少し違います。完全版サンプルではpaddingを補ってからUTF-8へ戻します。
function From-Base64Url([string]$Text) {
$b64 = $Text.Replace('-','+').Replace('_','/')
switch ($b64.Length % 4) {
2 { $b64 += '==' }
3 { $b64 += '=' }
0 { }
default { throw 'Base64URLの長さが不正です' }
}
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($b64))
}
$parts = $token.Split('.')
Write-Host "[RESULT] header = $(From-Base64Url $parts[0])"
Write-Host "[RESULT] payload = $(From-Base64Url $parts[1])"
1か所変えてみる
ダミーpayloadの role を reader から writer へ変えます。token文字列もdecode結果も簡単に変わります。
ここが重要です。読める・書き換えられることと、正しい署名を持つことは別です。署名付きJWTでは、受信側が署名等を検証して信頼性を判断します。
Microsoftのアクセストークンでは注意
Microsoftはaccess tokenを機密資格情報として扱うよう案内しています。また、クライアントアプリはaccess tokenをopaque stringとして扱うのが基本で、Microsoft API向けtokenが常に自分でdecodeすべきJWTだと決めつけない方が安全です。
実トークンをオンラインのdecoderへ貼り付ける教材にはしません。
仕事で使うなら
tokenをログへ出さない
実tokenを第三者サイトへ貼らない
decodeをsignature validationと呼ばない
JWT / JWS / JWEを混同しない
tokenの内容へ依存する前に対象APIの公式仕様を確認する
構造観察はダミーデータで十分です。
GitHubサンプル
公式情報・一次情報
まとめ
JWTの一部をdecodeできることは、暗号化や署名検証を意味しません。完全なダミーデータで「読む → 1か所変える」を試すと、payloadの可読性とtokenの信頼性を分けて理解できます。
