){kind=small}
JSONウェブトークン（JWT）のデバッグ方法
最近のウェブ・アプリケーションの多くは、クライアントサイドとサーバーサイドの両方で、認証にJSONウェブ・トークン（JWT）を使用しています。しかし、うまく機能しない場合、その原因を突き止めるのは難しい。
この投稿は、JWTの問題を理解し、修正するためのいくつかの戦術を提供することを目的としています。これから始める方は JWTとAPIを扱うためのドキュメントをご覧ください。をご覧ください。
問題は、正しい値を正しい場所に渡したかどうかという単純なことであることもある。
そこで、エラーログやコンソールなど、目に見える場所にJWTを出力するために、コードに少しデバッグを追加してください。
次に、以下のものを見てみよう：
これがトークンに見えますか？文字化けしたような英数字の文字列（厳密には、大文字と小文字、数字、
+と/が許され=はパディングのために使用されます）、ドットで区切られたものでなければなりません。末尾の改行を含め、空白があるか？厄介な、誤った空白は、いくつかのツールをつまずかせることがあります。
トークンはあるのだろうか？変数名を間違えてトークンを再生成したことが何度かあるのですが、問題はトークンではなく私にあると気づきました。
トークンが目視検査に合格したら、より具体的なツールを取り出す必要がある。
優れた JWTデバッグツール(ありがとう、Auth0！）がある。
JWTを左側のペインに貼り付け、解析されれば、3つのセクションの詳細が右側に表示される。
最初のセクションはヘッダーで、使用されるタイプとアルゴリズムを示す。Vonage APIコールに署名する場合、これは通常 typの JWTと algの RS256(のJWTになります。 Messages API 署名付きウェブフックの JWT はは HS256).
中央のセクションには、実際のデータがほとんど含まれている。ここには、JWTを使ったVonage APIコールで想定されるフィールドがいくつかある：
iatは "issued at "を表し、UNIXタイムスタンプでなければならない。expは「有効期限」で、UNIXタイムスタンプでもある。jtiは "JWT ID "を表し、一意な識別子でなければならない（フォーマットは指定されていない）。application_idはVonage API呼び出しに必要で、トークンの署名に使用された秘密鍵と一致する必要があります。
また subフィールド（クライアントSDKはこれを使用）または nbfこれは、このトークンが "Not Before "であることを示すタイムスタンプです。
jwt.ioデバッガーの3番目と最後のセクションは署名である。JWTは、ペイロードの一部にはならない秘密鍵で作成されます。
秘密鍵は基本的にあなたとVonageの間で共有される秘密です。このセクションのウェブインターフェイスに秘密鍵を追加することで、署名がチェックアウトされることを確認できます。
トークンだと思っていた問題が、まったく別のものだったということもある！ここでは、最初の2つのステップで解決できなかった場合に試してみるべき戦術をいくつか紹介しよう。
新しいアプリケーションの作成、新しいキーの生成、正しいファイル名の確認......。 private key-これらはすべて、本当は違いが出るはずのないステップだが、時には必要なものばかりだ。これは、JWTの問題に対する私の「1つの奇妙なトリック」だ。
トークンを生成し、アプリケーションで、またはお気に入りのHTTPクライアントから生のAPIコールで使用してみてください。
JWTは Nexmo CLIツールアプリケーションIDと秘密鍵を使って、次のようにJWTを生成できます：
nexmo jwt:generate path/to/private.key application_id=asdasdas-asdd-2344-2344-asdasdasd345あるいは、開発者ポータルにJWTを生成するためのウェブベースのヘルパーがあります： https://developer.nexmo.com/jwt.
故障箇所を見つけることは、それ自体がひとつのスキルセットであり、この投稿の中に、素晴らしいものを作るために前進するためのヒントがあれば幸いだ。もし、もっと共有すべきヒントがあれば、ぜひ教えてください！私たちは Twitter の @VonageDev.