このブログはこちらの英語ブログの機械翻訳です。
共有デバイスでの認証には、特有の課題が伴います。一部のシナリオは組織の従業員に固有のものですが、一部のユースケースはコンシューマーに固有のものです。この記事では、コンシューマーシナリオに焦点を当て、共有デバイス認証に安全に対処するための課題と可能なオプションについて検討します。
共有デバイス認証に関する課題
多くの組織やサービスが、顧客体験の向上、セルフサービスによる業務効率化、そして消費者増加に伴うスケーラビリティのために、キオスク端末や共有デバイスを採用しています。注目すべき例としては、小売店のPOS（販売時点情報管理）システム、エンターテイメント施設やイベント会場、ホテル、空港、図書館、医療機関などに設置されたキオスク端末があります。
消費者シナリオでは、主な課題は次のとおりです。
- ユーザーは公共のデバイスで認証情報を入力する必要があります。これにより、認証情報が漏洩するリスクが高まり、顧客の導入を妨げる可能性があります。
- ユーザーセッションは、明示的にサインアウトせずにシステムから離れた後もアクティブなままになる可能性があり、セッションの乗っ取りのリスクにつながります。
- パスキーなどのフィッシング耐性のある生体認証の適用は実現可能ではありません。
アプリケーションは、RFIDリーダー、公的書類、またはクレジットカードスキャナーの使用など、独自の方式で共有デバイス認証を処理することがよくあります。また、多くのシステムでは、図書館のコンピューターなど、従来のユーザーIDとパスワードによる認証を求められます。
共有デバイスによる認証の分離
より良い方法は、共有デバイス上で実行されているアプリケーションから認証を分離することです。認証を、ユーザーが所有するスマートフォンやタブレットなどの信頼できるデバイスを使用して実行できる場合、課題の一部をシームレスに解決できます。これらの課題の例としては、以下のようなものがあります。
- ユーザーは、共有デバイスで実行されているアプリケーションに資格情報や識別情報を提供する必要はありません。
- ユーザーが個人デバイスから認証するため、フィッシング対策の生体認証を簡単に使用できます。
有望なデカップリングされた認証標準を見てみましょう：OAuth 2.0 Device Authorization Grant
デバイス認可フローのご紹介
デバイス認可フローは元々、スマートテレビのような入力に制約のあるデバイスに、分離された認証を提供するために考案されました。多くの場合、このようなデバイスには、セキュアなフェデレーションフローを使用してユーザーが認証したり、認証情報を入力したりするための汎用ブラウザが搭載されていません。あるいは、認証情報の入力が煩雑です。デバイス認可フレームワークは、代わりにコンシューマーが自分の個人用デバイス（ラップトップ、モバイル、タブレット）を使って認証を実行できるようにする方法を提供します。
デバイス認可フローを主張する
デバイス認可フローは、共有デバイス認証シナリオにおいてエレガントなソリューションを提供します。考え方は次のとおりです。
- このアプリケーションは、ランダム化されたログインURLとユーザーコードを作成します。また、URLとユーザーコードをQRコードに埋め込むこともできます。その後、アプリケーションはユーザーに情報を表示します。
- ユーザーはQRコードをスキャンするか、デバイスのブラウザにログインリンクを手動で入力できます。
- 次に、彼らは自分のデバイスで認証フローを完了するために、自分の資格情報を提供します。機密性の高いアプリケーションの場合、認証プロセスには、パスキーなどのフィッシング耐性のある要素を含めることができます。
- 最後に、ユーザーコードを入力します。
- 認可プロセスが完了すると、共有デバイスアプリケーションは受信した認証トークンで続行されます。
ユーザーは、共有デバイスで認証情報を提供する必要はありません。（CIBAのように）認証チャレンジに同意する代わりに、信頼できるデバイスでエンドツーエンドの認証を実行します。
デバイス認証フローは、もともとTVやコマンドラインインターフェース（CLI）などの入力制約のあるデバイス向けに設計されました。ただし、共有デバイスでは、ユーザーの認証情報は安全ではなく、このフローは共有デバイス認証に最適です。
OAuth 2.0 device authorization flowの仕組みは次のとおりです。
セッション管理とログアウト
デバイス認可フローが共有デバイスの最前線認証に適している場合でも、アプリケーションまたはシステムはセッションとトークンを管理する必要があります。
トークンは有効期限が短く、TVやスマートデバイスのように長寿命のトークンが通常保証されている場合とは異なり、永続ストレージに保存しないでください。
アプリケーションは、ブラウザまたはアプリケーションが閉じられた直後にセッションをリセットし、アクセストークンとデバイスコードをクリアする必要もあります。
アプリケーションまたはデバイスは、ユーザーの非アクティブ状態を追跡し、短いしきい値内でタイムアウトする必要があります。タイムアウトすると、ユーザーセッションを速やかにリセットし、トークンをクリアする必要があります。
フォールバックオプション
認証に適した個人用デバイスをユーザーが所持していない場合はどうすればよいでしょうか？アプリケーションには、SMSやメール、OTPベースのパスワードレス認証など、適切なフォールバックログインオプションも用意する必要があります。完全を期すために、アプリケーションは従来のパスワードベースのログインも許可できますが、ユーザーに注意と指示メッセージを表示する必要があります。
Oktaはデバイス認可フローをサポートしています
Oktaは、OAuth 2.0仕様（RFC 8628）であるDevice Authorization Grant Flowのサポートを提供することにより、Identity and Access Management分野をリードし続けています。
Oktaは、さまざまなパスワードおよびパスワードレス認証方式をサポートする機能を備えているため、共有デバイスで実行されているアプリケーション向けに、信頼性の高い認証システムを簡単に実装できます。デバイス認証フローは、認証を共有デバイス自体から分離することで、ユーザーエクスペリエンスを向上させ、セキュリティを大幅に向上させます。Oktaは、APIおよびSDKを介した合理化された統合プロセスを提供することにより、この最新のプロトコルを簡単に利用できるようにします。企業が顧客とのやり取りに無人デバイスへの依存度を高めるにつれて、Oktaの先駆的なアプローチは、消費者にとって摩擦のない安全な認証体験を保証します。
デバイス認可フローは、元々は入力が制限されたデバイスの認証に対処するために考案されたものですが、共有デバイスからの消費者認証を処理するための優れたツールです。Oktaを使用すると、デバイス認可フローをすぐにサポートできるため、共有デバイス認証を安全に簡単に実装できます。
