トークンベースの認証とは？仕様とJWTのメリット、デメリット

トークンベースの認証とは、ユーザーが自分のアイデンティティを確認し、代わりに一意のアクセストークンを受け取ることを可能にするプロトコルです。トークンの存続期間中、ユーザーはトークンが発行されたWebサイトやアプリにアクセスできます。同じトークンで保護されたWebページ/アプリ/リソースに再度アクセスするたびに、資格情報を再入力する必要はありません。

認証トークンは、刻印されたチケットのように機能します。認証トークンが有効である限り、ユーザーはアクセスを保持します。ユーザーがログアウトするか、アプリケーションを終了すると、認証トークンは無効になります。

トークンベースの認証は、従来のパスワードベースまたはサーバーベースの認証手法とは異なります。認証トークンはセキュリティの第2レイヤーを提供し、管理者は各アクションとトランザクションを詳細に制御できます。

しかし、トークンを使用するには、コーディングに若干のノウハウが必要です。ほとんどの開発者は手法を素早く習得しますが、ある程度の学習も必要です。

掘り下げて理解することで、トークンが自身や自社に適しているかどうかを判断できるようになります。

→Okta Japanの資料請求はこちら

認証トークンの歴史

認証と認可は異なりますが、関連する概念です。認証トークンが登場する前は、パスワードとサーバーを使用していました。適切なユーザーが適切なタイミングで適切な対象にアクセスできるようにする上で、従来の方法は必ずしも効果的だったわけではありません。

パスワードの場合、一般的には以下が関与します。

ユーザーの生成。誰かが、文字/数字/記号の組み合わせを考えます。
記憶。その人物は、その一意の組み合わせを記憶する必要があります。
反復。そのユーザーが何かにアクセスする必要があるときは、毎回パスワードを入力する必要があります。

パスワードの窃取はよくあることです。実際、パスワード窃取の初期の記録は1962年まで遡ります。パスワードをすべて記憶できないために、ユーザーは以下のような方法でごまかそうとします。

すべてメモする。パスワードを紙切れにメモすることは、非常に大きなリスクです。
繰り返し使用する。複数の場所で同じパスワードを繰り返し使用する傾向が見られます。1つのパスワードが侵害されると、多くのアカウントが脆弱になる可能性があります。
少しだけ変える。パスワードの更新を求めるメッセージが表示されたときに、文字や数字を1つだけ変更する人がいます。

パスワードはサーバー認証も必要とします。ユーザーがログオンするたびに、コンピューターはトランザクションの記録を作成します。それに応じてメモリの負荷が増加します。

トークン認証は異なります。

トークン認証の場合、セカンダリサービスがサーバー要求を検証します。検証が完了すると、サーバーはトークンを発行し、要求に応答します。

ユーザーは依然としてパスワードを1つ記憶する必要があるかもしれませんが、トークンが提供するアクセス形式では窃取や侵害がはるかに困難です。また、セッションのレコードはサーバーの領域をあまり必要としません。

認証トークンの3つのタイプ

いずれの認証トークンもアクセスを許可しますが、タイプによって動作が若干異なります。

認証トークンには、一般的に以下の3タイプがあります。

接続：キー、ディスク、ドライブ、その他の物理的なアイテムがシステムに接続することで、アクセスできます。USBデバイスやスマートカードを使用するログインは、接続されたトークンを使用するアクセスです。
非接触：デバイスはサーバーと通信するために十分近くにありますが、接続はしません。Microsoftのいわゆる「マジックリング」は、この種のトークンの一例です。
切断：デバイスが長距離でサーバーと通信でき、別のデバイスに触れる必要はまったくありません。二要素認証プロセスで携帯電話を使用するログインは、このタイプのトークンを使用するアクセスです。

これら3つのシナリオのいずれでも、ユーザーがパスワードの入力や質問への回答といったアクションを実行すると、プロセスが開始します。しかし、これらの予備的な手順を完璧に実行しても、アクセストークンを利用しなければアクセスできません。

トークン認証の4つの簡単なステップ

トークンベースの認証システムを使用すると、資格情報を一度検証するだけでアクセスできます。このとき、特定の期間だけアクセスを許可するトークンがユーザーに付与されます。

このプロセスは、以下のように機能します。

要求：ユーザーが、サーバーまたは保護されたリソースへのアクセスを要求します。このとき、パスワードを使用したログインや、指定された他のプロセスが関与することがあります。
検証：サーバーが、ユーザーがアクセスしてよいと判断します。このとき、ユーザー名とパスワードの照合や、指定された他のプロセスが関与することがあります。
トークン：サーバーが、認証デバイス（リング、キー、携帯電話など）と通信します。検証後、サーバーはトークンを発行してユーザーに渡します。
ストレージ：動作が継続する間、トークンはユーザーのブラウザ内に留まります。

ユーザーがサーバーの別の部分にアクセスしようとすると、トークンはサーバーと再び通信します。アクセスは、トークンに基づいて許可または拒否されます。

管理者は、トークンの制限を設定します。たとえば、ユーザーがログアウトすると即座に破棄されるワンタイムトークンを設定できます。また、指定した期間が終了するときにトークンが自己破壊するように設定することも可能です。

JSON Web Token（JWT）とは：特殊な形式の認証トークン

今日、多くのユーザーが携帯電話（アプリ）やWebアプリからシステムにアクセスしているため、開発者はこれらのプラットフォームに適した安全な認証方法を必要としています。

この課題を解決するために、多くの開発者はアプリケーションでJSON Web Token（JWT）を採用しています。

JSON Web Token（JWT）はオープンスタンダードです。JWTを製品に使用することで、二者間で安全な通信を実現できます。データはデジタル署名で検証され、HTTP経由で送信される場合は暗号化によりデータの安全性が保持されます。

JWTには3つの重要なコンポーネントがあります。

ヘッダー：このスペースには、トークンのタイプと関与する署名アルゴリズムを定義します。
ペイロード：このセクションには、トークン発行者、トークンの有効期限などを定義します。
署名：安全な署名によって転送中にメッセージが変更されなかったことを確認します。

これらの要素がコーディングで結び付けられ、完成した製品はこのような外観になります。

JSONコードの使用に気後れすることはありません。このタイプの表記法は、エンティティ間でデータを受け渡しする場合に一般的であり、チュートリアルも豊富にあります。JSONトークンの使用に興味があっても、この言語を試したことがない場合は、このようなリソースが役立ちます。

JWTのメリットとデメリット

JWTには多くのメリットがあります。

サイズ：このコード言語のトークンは小さく、2つのエンティティ間で迅速に受け渡しできます。
使いやすさ：トークンは、ほぼどこからでも生成でき、サーバーで検証する必要はありません。
制御：ユーザーがアクセスできる対象、そのアクセス許可の持続時間、ログオン中に実行できる操作を指定できます。

その一方で、潜在的なデメリットもあります。

単一のキー：JWTは単一のキーに依存します。このキーが侵害されると、システム全体が危険にさらされます。
複雑さ：これらのトークンは簡単に理解できるものではありません。開発者が暗号署名アルゴリズムに関する知識を十分に持っていない場合、誤ってシステムを危険にさらす可能性があります。
制約：メッセージをすべてのクライアントにプッシュすることはできません。また、サーバー側からクライアントを管理することはできません。

認可トークンを試すべき理由

現在の戦略が順調に進んでいると評価する場合でも、あえて認証トークンをシステムに導入することには大きな意義があります。認証トークンを導入するという思い切った判断を下すことで、現実的なメリットが開発者にもたらされます。

システムが以下に該当する場合は、認証トークンが役立ちます。

一時アクセスを付与することがよくある。日によって、時間帯によって、または特別なイベントによってユーザーベースが変動する場合、アクセスの付与と無効化を頻繁に行うことは過剰な労力を要します。このようなとき、トークンが役に立ちます。
たとえば、大学の図書館サイトの管理者がトークンを使用すると有意義でしょう。
きめ細かいアクセスを必要とする。サーバーが、ユーザープロパティではなく、特定のドキュメントプロパティに基づいてアクセスを許可する場合、パスワードでは詳細を微調整できません。
たとえば、オンラインジャーナルを運営しており、他のドキュメントではなく特定のドキュメントだけを読んでコメントしてほしいと考える場合に、トークンが役立ちます。
ハッキングの主要ターゲットとなっている。サーバーに、侵害によって甚大な損害が生じる機密文書が格納されている場合、単純なパスワードは十分な保護を提供しません。ハードウェアを利用することが効果的です。

この他にも、認証トークンのユースケースは多くあります。しかし、このリストを足掛かりとし、さらにメリットを検討することで、認証トークンの採用に前向きになるでしょう。

認証トークン（トークンベースの認証）のベストプラクティス

認証トークンは、セキュリティプロトコルを強化してサーバーを安全に保つためのものですが、安全性を念頭に置いてプロセスを構築しなければ効果を上げることはできません。

認証トークンには、以下が必要とされます。

秘密であること。ユーザーによるトークン認証デバイスの共有や、部門間での受け渡しは認められません。パスワードを共有しないのと同様に、セキュリティシステムの他の部分を共有してはなりません。
安全であること。トークンとサーバー間の通信は、HTTPS接続を介する安全なものである必要があります。暗号化は、トークンを安全に保つ上で重要な要素です。
テスト済みであること。定期的にトークンのテストを実施して、システムが安全で正しく機能していることを確認します。問題を見つけたら、すぐに修正する必要があります。
適切であること。個々のユースケースに適したトークンタイプを選択します。たとえば、JWTはセッショントークンには向きません。コストが高いことがあり、また傍受に伴うセキュリティリスクを排除することは不可能です。必ずジョブに適したツールを選択してください。

認証トークンに関する意思決定を軽々しく下してはなりません。必要な準備を行い、同僚に相談し、自社にとって最良のジョブとなるように努めてください。