Skip to main content
Auth0 で CLI を保護する方法は、セキュリティが高い順に次の 3 つです。

​
Device Authorization Flow

インターネットに接続する入力手段が限られたデバイスでは、デバイスがユーザーを直接認証するのではなく、ユーザーにコンピューターやスマートフォンでリンク先を開いてデバイスを認可するよう求めます。これにより、文字を簡単に入力する手段がないデバイスでの使いにくさを避けられます。これを実現するために、デバイスアプリは Device (OAuth 2.0 で策定) を使用し、認可プロセスを開始してトークンを取得するために、自身の を送信します。 Device Authorization Flow を実装する最も簡単な方法は、Device Authorization Flow を使用して API を呼び出す の手順に従うことです。 における Device Authorization Flow についてさらに詳しく知りたい場合は、Internet Engineering Task Force (IEFT) のドラフト OAuth 2.0 Authorization Grant を参照してください。あわせて、Device Authorization Flow の記事もご覧ください。

​
クライアントクレデンシャルズグラントフロー

ユーザーや下流のが関与せず、個々のマシンやデバイスに対して認証を行いたい場合は、Client Credentials Grant (CCG) フローを使用します。 お使いのアイデンティティプロバイダーが認証情報の送信をサポートしている場合は、Client Credentials Flowの記事をご確認ください。このフローの実装方法について詳しくは、Call API Using the Client Credentials Flowを参照してください。

​
Resource Owner Password Grant フロー

ネイティブアプリケーションで Password Grant (ROPG) フローを使用することは推奨していません。IETF の記事 RFC 8252 OAuth 2.0 for Native Apps では、「ネイティブアプリからの OAuth 2.0 認可リクエストは、外部ユーザーエージェント (主にユーザーのブラウザー) を介してのみ行うべきである」と推奨されています。詳しくは、RFC 8252 Embedded User-Agents を参照してください。 Resource Owner Password Grant (ROPG) の使用は、上述のリダイレクトベースの方法に比べて安全性が低くなります。ROPG はレガシー用途専用です。CLI の文脈では、レガシープログラムをサポートする必要がある接続文字列のようなケースでのみ意味があります。 推奨している Device Flow ではなく、どうしてもネイティブアプリで ROPG を使用しなければならない場合は、OIDC 準拠の ROPG endpoint を使用できます。