デバイス認可フロー

ユーザーを直接認証するのではなく、入力に制約のあるインターネット接続デバイスでは、コンピューターやスマートフォンのリンクをクリックして、デバイスを認可するようユーザーに求めます。そうすることで、テキストを入力するのに手軽な方法がないデバイスで、ユーザーエクスペリエンスの質が下がることを防ぎます。これを行うには、デバイスアプリがデバイス認可フロー（OAuth 2.0で承認）を使用し、クライアントIDを渡して認可プロセスを開始し、トークンを取得します。

仕組み

デバイス認可フローは、認可を要求するデバイスのフローとブラウザーのフローという、2つのフローに分岐しています。ブラウザーの分岐フローでは、デバイスコードがブラウザーのセッションにバインドされ、デバイスの分岐フローと並行して処理されます。

フロー - デバイスの認可 - 認可シーケンスの図

デバイスフロー

  1. ユーザーがデバイスでアプリを起動します。

  2. デバイスアプリが、クライアントIDを使ってAuth0認可サーバーに認可を要求します（/oauth/device/codeエンドポイント）。

  3. Auth0認可サーバーはdevice_code、user_code、verification_uri、verification_uri_completeexpires_in（device_codeとuser_codeのライフタイムの秒数）、およびポーリングintervalで応答します。

  4. デバイスアプリが、コンピューターやスマートフォンを使って有効にすることを、ユーザーに求めます。アプリはこれを以下のようにして行うことができます。

    • これらの値を画面に表示した後、verification_uriに移動してuser_codeを入力するようにユーザーを促します

    • ユーザーにQRコードまたは短縮URLの使用を促します。この短縮URLにはverification_uri_completeから生成されたユーザーコードが埋め込まれています

    • ブラウザベースのデバイスでネイティブに実行する場合は、verification_uri_completeを使用して、ユーザーコードが埋め込まれた検証ページに直接移動させます

  5. デバイスアプリは、intervalで指定しされた期間を使用して、最後のポーリング要求の応答を受信してからの時間をカウントし、Auth0認可サーバーにアクセストークン（/oauth/tokenエンドポイント）のポーリングを開始します。デバイスアプリは、ユーザーがブラウザーフローを完了するか、ユーザーコードが期限切れになるまでポーリングを続けます。

  6. ユーザーがブラウザーの分岐フローを完了すると、Auth0の認可サーバーがアクセストークン（リフレッシュトークンは任意）で応答します。この時点で、デバイスアプリは期限切れになるdevice_codeを忘れる必要があります。

  7. デバイスアプリがアクセストークンを使ってAPIを呼び出し、ユーザーについての情報にアクセスします。

  8. APIが要求データで応答します。

ブラウザーフロー

  1. ユーザーは自身のコンピューターでverification_uriを訪問し、user_codeを入力して、有効化されるデバイスにuser_codeが表示されていることを確認します。ユーザーがその他のメカニズム（QRコードのスキャンなど）でverification_uri_completeを表示した場合には、デバイス確認のみが必要になります。

  2. Auth0認可サーバーはユーザーをログイン画面と、必要であれば、同意画面にリダイレクトします。

  3. ユーザーは構成されたログインオプションの1つを使用して認証を行い、場合によっては、デバイスアプリの承認を求める同意ページが表示されます。

  4. これで、デバイスアプリにAPIへのアクセスが許可されませした。

実装方法

デバイス認可フローを最も手軽に実装するには、「デバイス認可フローを使ってAPIを呼び出す」のチュートリアルを参照してください。

デバイスの再認証を強制する

ユーザーがデバイスで再認証することを強制するには、デバイスのリフレッシュトークンを失効させなくてはなりません。詳細については、「ユーザーからデバイスをリンク解除する」を参照してください。デバイスは、現在有効なアクセストークンの期限が切れて、アプリケーションが失効したリフレッシュトークンを使おうとするまでは、再認証が強制されないことに注意してください。リフレッシュトークンの詳細については、「リフレッシュトークン」をお読みください。

もっと詳しく