Auth0 で CLI を保護する

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

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

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

​

デバイス認可フロー

インターネットに接続する入力機能が限られたデバイスでは、デバイス上でユーザーを直接認証する代わりに、ユーザーにコンピューターやスマートフォンでリンク先にアクセスしてデバイスを認可してもらいます。これにより、文字入力を簡単に行えないデバイスでも、使い勝手の悪いユーザー体験を避けられます。これを実現するために、デバイスアプリは Device 認可フロー (OAuth 2.0 で策定) を使用し、クライアントID を渡して認可プロセスを開始し、トークンを取得します。

デバイス認可フローを実装する最も簡単な方法は、デバイス認可フローを使用して API を呼び出す の手順に従うことです。

OAuth 2.0 におけるデバイス認可フローの詳細については、Internet Engineering Task Force (IETF) のドラフト OAuth 2.0 Authorization Grant を参照してください。あわせて、デバイス認可フロー の記事も参照してください。

​

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

ユーザーや後段のIDプロバイダーが関与せず、個々のマシンまたはデバイスを識別して認証したい場合は、Client Credentials Grant (CCG) フローを使用します。

IDプロバイダーが認証情報の送信をサポートしている場合は、Client Credentials Flowの記事を確認してください。このフローの実装方法の詳細については、Call API Using the Client Credentials Flowを参照してください。

​

リソースオーナーパスワードグラントフロー

ネイティブアプリケーションで リソースオーナー 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 エンドポイント を使用できます。