> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# デバイス認可フロー

> デバイス認可フローの仕組みと、それをスマートテレビやメディアコンソールなど、入力に制約のあるデバイスで使用するべき理由について説明します。ネイティブアプリ用です。

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

## 仕組み

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

<Frame>
  <img src="https://mintcdn.com/docs-dev-actions-triggers-prototype/w3k2AH_K7Myvi2qD/docs/images/ja-jp/cdy7uua7fh8z/1A6jpG3W1H6SC9ZK92NyKd/d3a1211aa33afd8a94583a96a2f2e0cb/auth-sequence-device-auth.png?fit=max&auto=format&n=w3k2AH_K7Myvi2qD&q=85&s=9491435a29ee6435d65445a3853dd722" alt="フロー - デバイスの認可 - 認可シーケンスの図" width="1500" height="1543" data-path="docs/images/ja-jp/cdy7uua7fh8z/1A6jpG3W1H6SC9ZK92NyKd/d3a1211aa33afd8a94583a96a2f2e0cb/auth-sequence-device-auth.png" />
</Frame>

### デバイスフロー

1. ユーザーがデバイスでアプリを起動します。
2. デバイスアプリが、クライアントIDを使ってAuth0認可サーバーに認可を要求します（`/oauth/device/code`エンドポイント）。
3. Auth0認可サーバーは`device_code`、`user_code`、`verification_uri`、`verification_uri_complete``expires_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を呼び出す](/docs/ja-jp/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow)」のチュートリアルを参照してください。

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

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

## もっと詳しく

* [トークン](/docs/ja-jp/secure/tokens)
* [トークンのベストプラクティス](/docs/ja-jp/secure/tokens/token-best-practices)
* [どちらのOAuth 2.0フローを使用するべきですか？](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)
* [Auth0 Actions](/docs/ja-jp/customize/actions)
