記事5 JSON Web Tokens（JWT）を理解するための簡単な手順のかなり自由な翻訳を紹介します 。 この記事では、 JSON Web Token（JWT）とは何か、何を食べるのかについて説明します。 つまり、ユーザー認証とアプリケーションデータセキュリティで彼らはどのような役割を果たします。
最初に、正式な定義を検討します。
JSON Web Token (JWT)
は、オープンスタンダードRFC 7519で定義されているJSONオブジェクトです。 2人の参加者間で情報を転送する最も安全な方法の1つと考えられています。 トークンを作成するには、トークンに関する一般情報、ユーザーID、ロールなどのペイロードデータを含むヘッダーを定義する必要があります。 および署名。
ちなみに、正しくJWTは/dʒɒt/
簡単に言えば、 JWTは次のheader.payload.signature
形式の単なる文字列です。
サイトに登録したいとします。 この例では、ユーザーuser
、 application server
、 authentication server
3つの参加者がいauthentication server
。 認証サーバーはユーザーにトークンを提供し、その助けを借りて後でアプリケーションと対話できるようになります。
アプリケーションは、次のようにJWTを使用してユーザー認証を検証します。
- まず、ユーザーは認証キーを使用して認証サーバーにログオンします（ ユーザー名/パスワードのペア、 Facebookキー、 Googleキー、または別のアカウントのキーを使用できます）。
- 次に、認証サーバーはJWTを作成し、ユーザーに送信します。
- ユーザーがアプリケーションAPIに要求を行うと、以前に受信したJWTがそれに追加されます。
- ユーザーがAPIリクエストを行うと、アプリケーションは、 JWTリクエストを使用して、ユーザーが自分が主張するものであるかどうかを確認できます。 このスキームでは、アプリケーションサーバーは、着信JWTが認証サーバーによって作成されたものと正確に一致するかどうかを確認できるように構成されます（検証プロセスについては後で詳しく説明します）。
JWT構造
JWTは、ヘッダーheader
、 payload
データ、および署名signature
の3つの部分で構成されていsignature
。 それぞれを見ていきましょう。
ステップ1.ヘッダーを作成する
JWTヘッダーには、 JWT署名の計算方法に関する情報が含まれています。 ヘッダーは、次のようなJSONオブジェクトでもあります 。
header = { "alg": "HS256", "typ": "JWT"}
typ
フィールドは、 JSON Web Tokenであるというだけで、新しいことを教えません。 ここでより興味深いのは、ハッシュアルゴリズムを定義するalg
フィールドです。 署名の作成時に使用されます。 HS256
はHMAC-SHA256
他なりません;計算するには、1つの秘密鍵のみが必要です（詳細については、手順3を参照）。 別のRS256
アルゴリズムも使用できます。 RS256
アルゴリズムとは異なり、非対称であり、公開キーと秘密キーの2つのキーを作成します。 秘密鍵を使用して署名が作成され、公開鍵を使用して署名の信authentic性が検証されるだけなので、そのセキュリティについて心配する必要はありません。
ステップ2. PAYLOADを作成する
ペイロードは、 JWT内に格納されるペイロードです。 このデータはJWT-claimsとも呼ばれます。 検討している例では、認証サーバーはユーザーid - userIdに関する情報を使用してJWTを作成します。
payload = { "userId": "b08f86af-35da-48f2-8fab-cef3904660bd" }
ペイロードに 1つの要求だけを入れます。 必要な数のアプリケーションを配置できます。 JWTペイロードの標準アプリケーションのリストがあります -それらのいくつかはここにあります：
- iss （発行者）-トークンの送信元のアプリケーションを定義します。
- sub （subject）-トークンのトピックを定義します。
- exp （有効期限）-トークンの有効期間。
これらのフィールドは、 JWTを作成するときに役立ちますが、オプションです。 JWTで使用可能なフィールドのリスト全体を知りたい場合は、 Wikiをご覧ください。 ただし、送信される情報が多いほど、 JWT自体の結果が大きくなることを覚えておく価値があります。 通常、これには問題はありませんが、それでもパフォーマンスに悪影響を及ぼし、サーバーとの対話に遅延を引き起こす可能性があります。
ステップ3.署名を作成する
署名は、次の擬似コードを使用して計算されます。
const SECRET_KEY = 'cAtwa1kkEy' const unsignedToken = base64urlEncode(header) + '.' + base64urlEncode(payload) const signature = HMAC-SHA256(unsignedToken, SECRET_KEY)
base64urlアルゴリズムは、ステップ1および2で作成されたヘッダーとペイロードをエンコードします。 このアルゴリズムは、エンコードされた文字列をドットで連結します。 次に、結果の文字列は、秘密キーに基づいてヘッダーで指定されたアルゴリズムによってハッシュされます。
// header eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 // payload eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ // signature -xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM
ステップ4. 3つのJWTコンポーネントすべてを一緒に組み合わせる
3つのコンポーネントがすべて揃ったので、 JWTを作成できます。 それは非常に簡単で、受け取ったすべての要素をドットを介して線に接続します。
const token = encodeBase64Url(header) + '.' + encodeBase64Url(payload) + '.' + encodeBase64Url(signature) // JWT Token // eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM
jwt.ioで独自のJWTを作成してみてください。
例に戻りましょう。 これで、認証サーバーはJWTユーザーに送信できます。
JWTはデータをどのように保護しますか？
JWTを使用してもデータが自動的に非表示またはマスクされることはないことを理解することが非常に重要です。 JWTが使用される理由は、送信されたデータが実際に許可されたソースによって送信されたことを確認するためです。 上記で示したように、 JWT内のデータはエンコードおよび署名されますが、これは暗号化されたものとは異なることに注意してください。 データのエンコードの目的は、構造変換です。 署名されたデータにより、データ受信者はデータソースの認証を検証できます。 したがって、データのエンコードと署名はそれらを保護しません。 一方、暗号化の主な目的は、不正アクセスからデータを保護することです。 暗号化と暗号化の違い、およびハッシュの仕組みの詳細については、 この記事を参照してください 。 JWTはエンコードおよび署名されているだけであり、 JWTは暗号化されていないため、 JWTは機密データのセキュリティを保証しません。
ステップ5. JWTを確認する
単純な3メンバーの例では、 HS256
アルゴリズムを使用して署名されたJWTを使用し、認証サーバーとアプリケーションサーバーのみが秘密鍵を知っています。 アプリケーションサーバーは、認証プロセスのインストール中に認証サーバーから秘密鍵を受け取ります。 アプリケーションは秘密鍵を知っているため、ユーザーがトークンを添付したAPI要求を行うと、アプリケーションはステップ3と同じJWT署名アルゴリズムを実行できます。 アプリケーションは、独自の計算されたハッシュと比較することで、この署名を検証できます。 署名が一致する場合、 JWTは有効です。つまり、 信頼できるソースから来ました。 署名が一致しない場合、何かがおかしくなりました。おそらくこれは潜在的な攻撃の兆候です。 したがって、 JWTをチェックすることにより、アプリケーションはそれ自体とユーザーの間に信頼の層を追加します。
結論として
JWTの概要 、作成方法、検証方法、ユーザーとアプリケーション間の信頼を確立するための使用方法について説明しました。 しかし、これはアプリケーションの承認と保護の大きなトピックに関するパズルの一部にすぎません。 基礎だけを調べましたが、基礎なしでは先へ進むことはできません。
次は？
セキュリティについて考えて、 Refresh Token
を追加しましょう。 このトピックに関する次の記事を参照してください。