デバイス認可フローを使用してAPIを呼び出す

• Authentication API：APIを直接呼び出す方法については、このまま続けてお読みください。インタラクティブエクスペリエンスについては、「デバイスフロープレイグラウンド」をお読みください。

​

前提条件

• 制限事項（下記）を確認して、デバイス認可フローが実装に適しているかどうかを確認してください。
• Auth0にアプリケーションを登録します。
  • ［Application Type（アプリケーションタイプ）］ として ［Native（ネイティブ）］ を選択します。
  • 必要な場合は、［Allowed Web Origins（許可されたWebオリジン）］ を設定します。これを使用して、ローカル開発のオリジンとしてlocalhostを許可したり、CORSの対象となるアーキテクチャ（例：HTML5+JS）を持つ特定のTVソフトウェアの許可されたオリジンを設定したりできます。ほとんどのアプリケーションはこの設定は使用しません。
  • ［OIDC Conformant（OIDC準拠）］ トグルが有効になっていることを確認します。この設定は［Dashboard］の ［Applications（アプリケーション）］>［Application（アプリケーション）］>［Advanced Settings（アプリケーション設定）］>［OAuth］ にあります。
  • アプリケーションの ［Grant Types（付与タイプ）］ に ［Device Code（デバイスコード）］ が含まれていることを確認します。詳細については、「付与タイプを更新する」をお読みください。
  • アプリケーションがリフレッシュトークンを使用できるようにするには、アプリケーションの ［Grant Types（付与タイプ）］ に ［Refresh Token（リフレッシュトークン）］ が含まれていることを確認します。詳細については、「付与タイプを更新する」をお読みください。リフレッシュトークンの詳細については、「リフレッシュトークン」をお読みください。
• アプリケーションに少なくとも次の1つの接続をセットアップして有効にします：データベース接続、ソーシャル接続
• APIをAuth0に登録します。
  • APIがリフレッシュトークンを受信して、トークンの有効期限が切れたときに新しいトークンを取得できるようにするには、［Allow Offline Access（オンラインでのアクセスを許可する）］ を有効にします。リフレッシュトークンの詳細については、「リフレッシュトークン」をお読みください。
• デバイスのユーザーコードの設定を構成して、ランダムに生成されたユーザーコードの文字セット、形式、長さを定義します。

​

手順

1. デバイスコードの要求（デバイスフロー）：ユーザーがデバイスを認可するために使用できるデバイスコードを要求します。
2. デバイスのアクティベーションの要求（デバイスフロー）：ユーザーにノートパソコンまたはスマートフォンを使用してデバイスを認可するよう要求します。
3. トークンの要求（デバイスフロー）：トークンエンドポイントをポーリングし、トークンを要求します。
4. ユーザーの認可（ブラウザフロー）：デバイスがトークンを受け取れるように、ユーザーがデバイスを認可します。
5. トークンの受け取り（デバイスフロー）：ユーザーがデバイスを正常に認可すると、トークを受け取ります。
6. APIの呼び出し（デバイスフロー）：取得したアクセストークンを使ってAPIを呼び出します。
7. トークンのリフレッシュ（デバイスフロー）：既存のトークンが期限切れになったら、リフレッシュトークンを使用して新しいトークンを要求します。

​

デバイスコードを要求する

​

デバイスコードに対するPOSTの例URL

デバイスコードのパラメーター

• オーディエンスパラメーターを含めなければなりません
• ターゲットAPIによってサポートされている追加のスコープを含めなければなりません

​

デバイスコードの応答

{
  "device_code": "Ag_EE...ko1p",
  "user_code": "QTZL-MCBW",
  "verification_uri": "https://accounts.acmetest.org/activate",
  "verification_uri_complete": "https://accounts.acmetest.org/activate?user_code=QTZL-MCBW",
  "expires_in": 900,
  "interval": 5
}

• device_codeは、デバイスに対して一意のコードです。ユーザーがブラウザベースのデバイスでverification_uriにアクセスすると、このコードはセッションにバインドされます。
• user_codeには、デバイスを認可するためにverification_uriに入力する必要のあるコードが含まれます。
• verification_uriには、ユーザーがデバイスを認可するためにアクセスする必要があるURLが含まれます。
• verification_uri_completeには、ユーザーがデバイスを認可するためにアクセスする必要がある完全なURLが含まれています。これにより、必要に応じてアプリでURLにuser_codeを埋め込むことができます。
• expires_inは、device_codeおよびuser_codeの有効期間（秒）を示します。
• intervalは、アプリがトークンを要求するためにトークンURLをポーリングする間隔（秒）を示します。

​

デバイスのアクティベーションを要求する

​

トークンを要求する

​

トークンURLに対するトークンPOST要求の例

トークン要求のパラメーター

​

トークンの応答

認可待ち

HTTP/1.1 403 Forbidden
{
  "error": "authorization_pending",
  "error_description": "..."
}

減速

HTTP/1.1 429 Too Many Requests
{
  "error": "slow_down",
  "error_description": "..."
}

有効期限切れのトークン

HTTP/1.1 403 Bad Request
{ 
  "error": "expired_token",
  "error_description": "..."
}

アクセスが拒否されました

HTTP/1.1 403 Forbidden
{
  "error": "access_denied",
  "error_description": "..."
}

• ユーザーがデバイスの認可を拒否した
• 認可サーバーがトランザクションを拒否した
• 構成されたルールによってアクセスが拒否された（詳細については、「Auth0ルール」をお読みください）

​

ユーザーを認可する

• ユーザーを認証する
• 認証を行うために、ユーザーをIDプロバイダーへリダイレクトする
• アクティブなSSOセッションをチェックする
• 事前に同意が得られていない場合、デバイスに対するユーザーの同意を取得する

​

トークンを受け取る

{
  "access_token":"eyJz93a...k4laUWw",
  "refresh_token":"GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type":"Bearer",
  "expires_in":86400
}

​

APIを呼び出す

​

リフレッシュトークン

• オフラインアクセスを許可するように、APIを構成する。
• 認可エンドポイントを通じて認証要求を開始するときにoffline_accessスコープを含める。

​

トークンURLに対するリフレッシュトークンのPOST要求の例

リフレッシュトークン要求パラメーター

​

リフレッシュトークンの応答

{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "id_token": "eyJ...0NE",
  "token_type": "Bearer"
}

​

サンプルユースケース

​

デバイス認可フローの使用を検出する

function (user, context, callback) {
   if (context.protocol === 'oauth2-device-code') {
      ...
   }
 
   callback(null, user, context);
}

​

実装例

• デバイス認可プレイグラウンド
• AppleTV（Swift）：AppleTVからのデバイス認可フローにAuth0を使用できることを示す簡素なアプリケーションです。
• CLI（Node.js）：認可コードフローではなく、デバイス認可フローを使用するCLIの実装例です。CLIではWebサーバーをホストしてポートを待ち受ける必要がない点で大きく異なります。

​

トラブルシューティング

​

エラーコード

​

制限事項

• カスタムドメインの使用にServer Name Indication（SNI）をサポートしている
• Auth0アプリケーションタイプが ［Native（ネイティブ）］ である
• トークンエンドポイントの認証方法が ［None（なし）］ に設定されている
• OIDCに準拠している
• 動的クライアント登録（Dynamic Client Registration）で作成されていない

• ソーシャル接続にAuth0開発者キーを使用する（ユニバーサルログインエクスペリエンスを使用していない場合）
• クエリ文字列パラメーターへのアクセスをホスト済みのログインページまたはルールから行う
• ユーザーアカウントをリンクする

​

もっと詳しく

• OAuth 2.0の認可フレームワーク
• OpenID Connectのプロトコル
• トークン
• ログ