OAuth 2.0 デバイスフローの簡単な紹介

この記事では、ブラウザがないためユーザーエージェントベースの認証を行えない、または入力が制約されているデバイスでのアイデンティティ認証のソリューションである OAuth 2.0 デバイスフローについて、その目的とユーザーのインタラクションフローを概説します。

Yijun

Developer

12/5/2023

ユーザー認証に何週間も費やすのはもうやめましょう

Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。

始めましょう

認可フレームワークとして、OAuth 2.0 はさまざまなシナリオで広く使用されています。OAuth が提供する認証フローの中で最も一般的なものは Authorization Code Flow です。ユーザーがアプリケーション内で Authorization Code Flow を使用して自分のアイデンティティを認証する際、アプリはデバイスからブラウザを開いて認証エンドポイントにアクセスし、ユーザーは自分の識別情報（ユーザー名、メールなど）と認証情報（パスワード、確認コードなど）を入力して認証を完了します。

しかし、ブラウザがない、またはアカウントの認証情報を入力する能力がないデバイスでユーザーがアプリを使用しようとする場合、OAuth 2.0 を通じてどのようにアイデンティティ認証を行うのでしょうか？ここで「デバイスフロー」が役立ちます。

OAuth 2.0 デバイスフローとは

OAuth 2.0 デバイスフローは、入力機能が限定されているか、適切なブラウザが欠けているデバイスをサポートするように設計された OAuth 2.0 プロトコルの実装です。これらのデバイスには、スマート TV、IoT デバイス、プリンターなどが含まれます。

デバイスフローでは、ユーザーがこれらのデバイスで認可要求を開始し、その後、ブラウザアクセスと入力機能を持つ他のデバイス（スマートフォンやパソコンなど）を通じてユーザーが認可要求を確認し、ユーザー認可を完了することができます。

また、デバイスフローは CLI ツール（Stripe、Github、Cloudflare などが提供するもの）にしばしば使用されます。CLI ツールは、グラフィカルインターフェイスのないオペレーティングシステムで実行されることが多いためです。

デバイスフローを使用する際のユーザーインタラクションフロー

ユーザーが認証のためにデバイスフローを使用する場合、主に次の手順を含みます：

デバイスクライアントは、クライアント識別子（通常は認可サーバープラットフォームのクライアント ID）を使用して認可を要求します。
認可サーバーは、デバイスクライアントにデバイスコード、ユーザーコード、検証 URI を応答します。
デバイスクライアントは、検証 URI とユーザーコードをユーザーにテキスト（または QR コードなど）で表示し、ユーザーに URI を訪問しコードを入力するよう指示します。
ステップ 3 と同時に、デバイスクライアントは認可サーバーからデバイスコードとクライアント識別子を使用してアクセストークンのポーリングを開始し、ユーザーが認可要求を確認しユーザー認可を完了するのを待機します。
ユーザーは認可サーバーがホストする検証 URI を、別のデバイスのブラウザで訪問し、ユーザーコードを入力します。
認可サーバーはユーザーをサインインページにリダイレクトし、サインインを完了するよう指示します。
ユーザーはサインインフローを完了し、成功裏にサインインします。
認可サーバーはユーザーをサインイン成功ページにリダイレクトし、ブラウザを閉じるよう指示します。
ステップ 8 と同時に、認可サーバーはデバイスクライアントにアクセストークンを返します。クライアントはステップ 4 からポーリングしているためです。

これらのプロセスが完了すると、デバイスクライアントは後続のサービスに対してアクセストークンを取得できるようになります！

まとめ

ご覧の通り、OAuth 2.0 デバイスフローは、入力機能やブラウザがないデバイスのためにユーザーフレンドリーなサインイン方法を提供します。これは、スマート TV、IoT デバイス、グラフィカルインターフェイスがないデバイス上で動作する CLI ツールにとって重要です。

Logto がデバイスフロー機能をサポートするプロセスにあるというエキサイティングなニュースが届きました。最新の更新情報とともにお知らせしますのでお楽しみに。

今すぐ Logto を試す

OAuth 2.0 デバイスフローとは

デバイスフローを使用する際のユーザーインタラクションフロー

ユーザーが認証のためにデバイスフローを使用する場合、主に次の手順を含みます：

デバイスクライアントは、クライアント識別子（通常は認可サーバープラットフォームのクライアント ID）を使用して認可を要求します。

認可サーバーは、デバイスクライアントにデバイスコード、ユーザーコード、検証 URI を応答します。

デバイスクライアントは、検証 URI とユーザーコードをユーザーにテキスト（または QR コードなど）で表示し、ユーザーに URI を訪問しコードを入力するよう指示します。

ステップ 3 と同時に、デバイスクライアントは認可サーバーからデバイスコードとクライアント識別子を使用してアクセストークンのポーリングを開始し、ユーザーが認可要求を確認しユーザー認可を完了するのを待機します。

ユーザーは認可サーバーがホストする検証 URI を、別のデバイスのブラウザで訪問し、ユーザーコードを入力します。

認可サーバーはユーザーをサインインページにリダイレクトし、サインインを完了するよう指示します。

ユーザーはサインインフローを完了し、成功裏にサインインします。

認可サーバーはユーザーをサインイン成功ページにリダイレクトし、ブラウザを閉じるよう指示します。

ステップ 8 と同時に、認可サーバーはデバイスクライアントにアクセストークンを返します。クライアントはステップ 4 からポーリングしているためです。

これらのプロセスが完了すると、デバイスクライアントは後続のサービスに対してアクセストークンを取得できるようになります！

まとめ

OAuth 2.0 デバイスフローとは#

デバイスフローを使用する際のユーザーインタラクションフロー#

まとめ#

OAuth 2.0 デバイスフローとは#

デバイスフローを使用する際のユーザーインタラクションフロー#

まとめ#

OAuth 2.0 デバイスフローとは

デバイスフローを使用する際のユーザーインタラクションフロー

まとめ

OAuth 2.0 デバイスフローとは

デバイスフローを使用する際のユーザーインタラクションフロー

まとめ