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

> Auth0 を使用して CLI を保護する方法。

# Auth0 で CLI を保護する

Auth0 を使用して CLI を保護する方法は、最も安全なものから順に次の 3 つです。

* ユーザーがブラウザーを開けない場合は、[デバイス認可フロー](#device-authorization-flow)
* ユーザーに紐付けられず、アプリケーション自体として動作する場合は、[クライアントクレデンシャルグラントフロー](#client-credentials-grant-flow)
* CLI クライアント自体を認証しようとしている場合に限り、[リソースオーナーパスワードグラントフロー](#resource-owner-password-grant-flow) を使用します。これは非常にまれなケースです (それ以外では非推奨)

<div id="device-authorization-flow">
  ## デバイス認可フロー
</div>

インターネットに接続する入力機能が限られたデバイスでは、デバイス上でユーザーを直接認証する代わりに、ユーザーにコンピューターやスマートフォンでリンク先にアクセスしてデバイスを認可してもらいます。これにより、文字入力を簡単に行えないデバイスでも、使い勝手の悪いユーザー体験を避けられます。これを実現するために、デバイスアプリは Device <Tooltip tip="認可フロー: OAuth 2.0 フレームワークで規定された認可グラント（またはワークフロー）。" cta="用語集を見る" href="/ja/docs/glossary?term=Authorization+Flow">認可フロー</Tooltip> (OAuth 2.0 で策定) を使用し、<Tooltip tip="クライアントID: Auth0 から登録済みリソースに付与される識別値。" cta="用語集を見る" href="/ja/docs/glossary?term=Client+ID">クライアントID</Tooltip> を渡して認可プロセスを開始し、トークンを取得します。

デバイス認可フローを実装する最も簡単な方法は、[デバイス認可フローを使用して API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow) の手順に従うことです。

<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/ja/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> におけるデバイス認可フローの詳細については、Internet Engineering Task Force (IETF) のドラフト [OAuth 2.0 Authorization Grant](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15) を参照してください。あわせて、[デバイス認可フロー](/ja/docs/get-started/authentication-and-authorization-flow/device-authorization-flow) の記事も参照してください。

<div id="client-credentials-grant-flow">
  ## クライアントクレデンシャルグラントフロー
</div>

ユーザーや後段の<Tooltip tip="IDプロバイダー（IdP）：デジタルアイデンティティを保存および管理するサービス。" cta="用語集を表示" href="/ja/docs/glossary?term=identity+providers">IDプロバイダー</Tooltip>が関与せず、個々のマシンまたはデバイスを識別して認証したい場合は、Client Credentials Grant (CCG) フローを使用します。

IDプロバイダーが認証情報の送信をサポートしている場合は、[Client Credentials Flow](/ja/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)の記事を確認してください。このフローの実装方法の詳細については、[Call API Using the Client Credentials Flow](/ja/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow)を参照してください。

<div id="resource-owner-password-grant-flow">
  ## リソースオーナーパスワードグラントフロー
</div>

ネイティブアプリケーションで <Tooltip tip="リソースオーナー: 保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。" cta="用語集を見る" href="/ja/docs/glossary?term=Resource+Owner">リソースオーナー</Tooltip> Password Grant (ROPG) フローを使用することは推奨されません。IETF の記事 [RFC 8252 OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252) では、「ネイティブアプリからの OAuth 2.0 認可リクエストは、主にユーザーのブラウザーなどの外部ユーザーエージェントを介してのみ行うべきである」と推奨されています。詳しくは、[RFC 8252 Embedded User-Agents](https://tools.ietf.org/html/rfc8252#section-8.12) を参照してください。

Resource Owner Password Grant (ROPG) は、前述のリダイレクトベースの方法に比べて安全性が低くなります。ROPG はレガシー用途専用です。CLI の文脈では、レガシープログラムをサポートする必要がある接続文字列のようなケースでのみ意味があります。

推奨している Device Flow ではなく、どうしてもネイティブアプリで ROPG を使用する必要がある場合は、[OIDC 準拠の ROPG エンドポイント](https://auth0.com/docs/api/authentication#resource-owner-password) を使用できます。