要約
トークンベース認証では、1回限りの検証後に発行される、有効期間が限定されたアクセストークンを使用することで、繰り返しパスワードを入力する必要がなくなります。トークンには、接続型、非接触型、非接続型の3つの物理的な形態があり、4つのステップで実装できます。JSON Web Token（JWT）は、モバイルアプリやWebアプリに適した、普及しているオープンスタンダードなトークンです。コンパクトなサイズときめ細かいアクセス制御を提供しますが、暗号鍵の管理を誤るとリスクが生じます。安全な実装のためには、トークンを非公開にして暗号化し、テストを行い、ユースケースに適合させるといったベストプラクティスに従うことが不可欠です。
トークンベースの認証とは？ 仕様とJWTのメリット、デメリット
トークンベースの認証とは、ユーザーが自分のアイデンティティを確認し、代わりに一意のアクセストークンを受け取ることを可能にするプロトコルです。トークンの存続期間中、ユーザーはトークンが発行されたWebサイトやアプリにアクセスできます。同じトークンで保護されたWebページ/アプリ/リソースに再度アクセスするたびに、資格情報を再入力する必要はありません。
認証トークンは、刻印されたチケットのように機能します。認証トークンが有効である限り、ユーザーはアクセスを保持します。ユーザーがログアウトするか、アプリケーションを終了すると、認証トークンは無効になります。
トークンベースの認証は、従来のパスワードベースまたはサーバーベースの認証手法とは異なります。認証トークンはセキュリティの第2レイヤーを提供し、管理者は各アクションとトランザクションを詳細に制御できます。
しかし、トークンを使用するには、コーディングに若干のノウハウが必要です。ほとんどの開発者は手法を素早く習得しますが、ある程度の学習も必要です。
掘り下げて理解することで、トークンが自身や自社に適しているかどうかを判断できるようになります。
認証トークンはどのようにして生まれたのでしょうか？
認証と認可は異なりますが、関連する概念です。認証トークンが登場する前は、パスワードとサーバーがありました。従来の方法を使用して、適切な人が適切なタイミングで適切なものにアクセスできるようにしました。必ずしも効果的ではありませんでした。
パスワードの場合、一般的には以下が関与します。
- ユーザー生成。誰かが、文字/数字/記号の組み合わせを考えます。
- メモリ。その人物は、その一意の組み合わせを記憶する必要があります。
- 反復。そのユーザーが何かにアクセスする必要があるときは、毎回パスワードを入力する必要があります。
パスワードの窃取はよくあることです。実際、パスワード窃取の初期の記録は1962年まで遡ります。パスワードをすべて記憶できないために、ユーザーは以下のような方法でごまかそうとします。
- すべて書き留める。パスワードを紙切れにメモすることは、非常に大きなリスクです。
- 繰り返すこと。複数の場所で同じパスワードを繰り返し使用する傾向が見られます。1つのパスワードが侵害されると、多くのアカウントが脆弱になる可能性があります。
- わずかに変更を加えます。パスワードの更新を求めるメッセージが表示されたときに、文字や数字を1つだけ変更する人がいます。
パスワードはサーバー認証も必要とします。ユーザーがログオンするたびに、コンピューターはトランザクションの記録を作成します。それに応じてメモリの負荷が増加します。
トークン認証とパスワードの違いは何ですか？
トークン認証は異なります。
トークン認証では、セカンダリサービスがサーバーリクエストを検証します。検証が完了すると、サーバーはトークンを発行し、要求に応答します。
ユーザーは依然としてパスワードを1つ記憶する必要があるかもしれませんが、トークンが提供するアクセス形式では窃取や侵害がはるかに困難です。また、セッションのレコードはサーバーの領域をあまり必要としません。
認証トークンにはどのような種類がありますか？
すべての認証トークンはアクセスを許可しますが、各タイプは少し異なる方法で動作します。
これらは、一般的な3つの認証トークンの種類です。
- 接続：キー、ディスク、ドライブ、その他の物理的なアイテムがシステムに接続することで、アクセスできます。システムへのログインにユニバーサルシリアルバス（USB）デバイスやスマートカードを使用したことがあるなら、それはコネクテッドトークンを使用したことになります。
- 非接触：デバイスはサーバーと通信するために十分近くにありますが、接続はしません。Microsoftのいわゆる「マジックリング」は、この種のトークンの一例です。
- 切断：デバイスが長距離でサーバーと通信でき、別のデバイスに触れる必要はまったくありません。二要素認証プロセスで携帯電話を使用するログインは、このタイプのトークンを使用するアクセスです。
これら3つのシナリオのいずれでも、ユーザーがパスワードの入力や質問への回答といったアクションを実行すると、プロセスが開始します。しかし、これらの予備的な手順を完璧に実行しても、アクセストークンを利用しなければアクセスできません。
トークン認証の仕組み
トークンベースの認証システムを使用すると、資格情報を一度検証するだけでアクセスできます。このとき、特定の期間だけアクセスを許可するトークンがユーザーに付与されます。
このプロセスは、以下のように機能します。
- 要求：ユーザーが、サーバーまたは保護されたリソースへのアクセスを要求します。このとき、パスワードを使用したログインや、指定された他のプロセスが関与することがあります。
- 検証：サーバーが、ユーザーがアクセスしてよいと判断します。このとき、ユーザー名とパスワードの照合や、指定された他のプロセスが関与することがあります。
- トークン：サーバーが、認証デバイス（リング、キー、携帯電話など）と通信します。検証後、サーバーはトークンを発行してユーザーに渡します。
- ストレージ：動作が継続する間、トークンはユーザーのブラウザ内に留まります。
トークンセッションはどのように管理され、期限切れになりますか？
ユーザーがサーバーの別の部分にアクセスしようとすると、トークンはサーバーと再び通信します。アクセスは、トークンに基づいて許可または拒否されます。
管理者は、トークンの制限を設定します。たとえば、ユーザーがログアウトすると即座に破棄されるワンタイムトークンを設定できます。また、指定した期間が終了するときにトークンが自己破壊するように設定することも可能です。
JSON Web Token（JWT）とは何ですか？
今日、多くのユーザーが携帯電話（アプリ）やWebアプリからシステムにアクセスしているため、開発者はこれらのプラットフォームに適した安全な認証方法を必要としています。
この課題を解決するために、多くの開発者はアプリケーションでJSON Web Token（JWT）を採用しています。
JSON Web Token（JWT）はオープンスタンダードです。 JWTを製品に使用することで、二者間で安全な通信を実現できます。データはデジタル署名で検証され、Hypertext Transfer Protocol（HTTP）で送信される場合は、暗号化によってデータのセキュリティが確保されます。
JWTの3つの構成要素とは何ですか？
JWTには3つの重要なコンポーネントがあります。
- ヘッダー：このスペースには、トークンのタイプと関与する署名アルゴリズムを定義します。
- ペイロード：このセクションには、トークン発行者、トークンの有効期限などを定義します。
- 署名：安全な署名によって転送中にメッセージが変更されなかったことを確認します。
これらの要素がコーディングで結び付けられ、完成した製品はこのような外観になります。
JSON Web Tokenの利用を開始するにはどうすればよいですか？
JSONコードの使用に気後れすることはありません。 このタイプの表記法は、エンティティ間でデータを受け渡しする場合に一般的であり、チュートリアルも豊富にあります。JSONトークンの使用に興味があっても、この言語を試したことがない場合は、このようなリソースが役立ちます。
JWTのメリットとデメリットは何ですか？
JWTにはいくつかのメリットがありますが、考慮に値する注目すべきトレードオフも存在します。
| 長所 | 短所 |
|---|---|
| サイズ：トークンはサイズが非常に小さく、エンティティ間ですばやく受け渡しされます。 | 単一のキー：キーが侵害されると、システム全体が危険にさらされます。 |
| 容易さ：トークンは、サーバー側の検証なしに、ほぼどこからでも生成できます。 | 複雑さ：暗号署名アルゴリズムに関する高度な知識が必要です。 |
| 制御：アクセスのスコープ、期間、権限を指定します。 | 制限事項：すべてのクライアントにメッセージをプッシュしたり、サーバー側でクライアントを管理したりすることはできません。 |
認可トークンを試すべき理由
現在の戦略が順調に進んでいると評価する場合でも、あえて認証トークンをシステムに導入することには大きな意義があります。認証トークンを導入するという思い切った判断を下すことで、現実的なメリットが開発者にもたらされます。
システムが以下に該当する場合は、認証トークンが役立ちます。
- 一時的なアクセスを許可することがよくあります。ユーザーベースは、日付、時間、または特別なイベントに基づいて変動します。アクセス権を繰り返し付与および取り消すのは、非常に煩雑です。このようなとき、トークンが役に立ちます。
たとえば、大学の図書館サイトの管理者がトークンを使用すると有意義でしょう。
- きめ細かいアクセスを要求します。サーバーは、ユーザープロパティではなく、特定のドキュメントプロパティに基づいてアクセスを許可します。パスワードでは、その微調整された詳細は許可されません。
たとえば、オンラインジャーナルを運営しており、他のドキュメントではなく特定のドキュメントだけを読んでコメントしてほしいと考える場合に、トークンが役立ちます。
- ハッキングの主要ターゲットとなっている。サーバーに、侵害によって甚大な損害が生じる機密文書が格納されている場合、単純なパスワードは十分な保護を提供しません。ハードウェアを利用することが効果的です。
この他にも、認証トークンのユースケースは多くあります。しかし、このリストを足掛かりとし、さらにメリットを検討することで、認証トークンの採用に前向きになるでしょう。
認証トークンのベストプラクティスとは何ですか？
認証トークンは、セキュリティプロトコルを強化してサーバーを安全に保つためのものですが、安全性を念頭に置いてプロセスを構築しなければ効果を上げることはできません。
認証トークンには、以下が必要とされます。
- プライベート。ユーザーによるトークン認証デバイスの共有や、部門間での受け渡しは認められません。パスワードを共有しないのと同様に、セキュリティシステムの他の部分を共有してはなりません。
- セキュリティ保護。トークンとサーバー間の通信は、HTTPS（Hypertext Transfer Protocol Secure）接続を介してセキュリティを確保する必要があります。暗号化は、トークンを安全に保つ上で重要な要素です。
- テスト済み。定期的にトークンのテストを実施して、システムが安全で正しく機能していることを確認します。問題を見つけたら、すぐに修正する必要があります。
- 適切。個々のユースケースに適したトークンタイプを選択します。たとえば、JWTはセッショントークンには向きません。コストが高いことがあり、また傍受に伴うセキュリティリスクを排除することは不可能です。必ずジョブに適したツールを選択してください。
認証トークンに関する意思決定を軽々しく下してはなりません。必要な準備を行い、同僚に相談し、自社にとって最良のジョブとなるように努めてください。
Oktaのトークン認証導入支援
家庭やオフィスへのアクセス保護を継続的に評価する中、トークン認証などのメカニズムを実装して、適切なユーザーによるデジタルリソースへのアクセスを保証することも重要です。
Oktaを活用することで保護を強化できます。その方法をご確認ください。
よくある質問（FAQ）
トークンベース認証とパスワードベース認証の違いは何ですか？
パスワードベースの認証では、ユーザーはリソースにアクセスするたびに認証情報を入力する必要があり、その認証情報はサーバーの記録と照合されます。トークンベースの認証では、1回の検証後に有効期限付きのトークンが発行されるため、ユーザーは認証情報を再入力することなく、保護されたリソースにアクセスできます。また、トークンはサーバーにセッションレコードを残さないため、メモリの負荷が軽減されます。
認証トークンの有効期間はどのくらいですか？
トークンの有効期間は管理者が設定します。トークンは、ユーザーがログアウトするとすぐに無効になるシングルユースとして設定することも、定義した期間が経過すると失効するように設定することもできます。トークンの有効期限が切れたり無効になったりした場合、ユーザーは再認証して新しいトークンを取得する必要があります。
認証トークンに3つの種類があるそうですが、それぞれどのようなものですか？
認証トークンは、システムとの連携方法によって、物理的なプラグインデバイス（接続型）、ワイヤレスの近接型デバイス（非接触型）、2要素認証で使用されるスマートフォンなどのリモートデバイス（非接続型）の3つのカテゴリーに分類されます。
他の種類のトークンではなく、JSON Web Token（JWT）を使用すべきなのはどのような場合でしょうか？
JWTはコンパクトで、ほぼどこからでも生成でき、サーバーサイドでの検証が不要なため、モバイルアプリやWebアプリケーションに適しています。ただし、コストや傍受のリスクがあるため、セッショントークンには理想的ではありません。開発者は、他のトークン形式よりもJWTを選択する前に、特定のユースケースを評価する必要があります。
認証トークンに関連する最大のセキュリティリスクとは何ですか？
主なリスクとして、JWTに単一の暗号化キーを使用すること（侵害された場合、システム全体が危険にさらされます）、安全でない通信チャネルを使用すること（トークンはHTTPSで送信する必要があります）、ユーザー間でトークンを共有することなどが挙げられます。暗号アルゴリズムに関する深い知識を持たない開発者が、意図せず脆弱性を生み出してしまう可能性もあります。
認証トークンを実装する際に、組織が従うべきベストプラクティスとは何ですか？
トークンは非公開とし、ユーザー間で共有しないでください。トークンとサーバー間のすべての通信は、暗号化されたHTTPS接続を使用する必要があります。組織は、システムの完全性を検証するために定期的なテストを実行する必要があります。また、管理者は特定のユースケースに最適なトークンの種類を選択する必要があります。たとえば、よりシンプルでリスクの低い代替手段が存在する場合は、セッション管理にJWTを使用しないようにします。
参考文献
世界初のコンピューターパスワードも役に立たなかった。（2012年1月）。Wired
Microsoft、魔法の指輪でパスワードが不要になる可能性を示唆。（2020年6月、Small Business Trends
JSON Web Token。（2021年5月、Internet Engineering Task Force.
JSONの操作。Mozilla。
セキュリティトークン。シティ。
セキュリティトークンの定義。（2020年6月、Investopedia。
2 要素認証。 （2020年2月、仕組みを解説。
トークンはいつ有価証券になるのか？当惑する人々からのいくつかの質問。（2018 年12月、Harvard Law School Forum on Corporate Governance
