Auth0でCLIを保護する

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

CLIをAuth0で保護するには、次の3通りの方法があります。以下、最も安全な方法から順に挙げます。

• ユーザーがブラウザーを開けない場合のデバイス認可フロー
• ユーザーに紐づけられず、自身の名義で動作するアプリケーション用のクライアント資格情報付与フロー
• 非常に稀なケースで、CLIクライアント自体を認証しようとする場合にのみ使用される（それ以外の場合は推奨されない）リソース所有者のパスワード付与フロー

​

デバイス認可フロー

OAuth 2.0で策定）を使用し、クライアントIDを渡して認可プロセスを開始し、トークンを取得します。

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

OAuth 2.0におけるデバイス認可フローの詳細については、Internet Engineering Task Force (IETF) の草案「OAuth 2.0 Authorization Grant（OAuth 2.0認可付与）」をお読みください。また、弊社の記事「デバイス認可フロー」も合わせてお読みください。

​

クライアント資格情報付与フロー

ユーザーや下流のアイデンティティプロバイダーが関与せず、個別のマシンやデバイスに基づいて認証を行いたい場合は、クライアント資格情報付与（CCG）フローを使用します。

ご利用のアイデンティティプロバイダーが資格情報の送信をサポートしている場合は、弊社の記事「クライアント資格情報フロー」を参照してください。このフローを実装方法の詳細については、「クライアント資格情報フローを使用してAPIを呼び出す」を参照してください。

​

リソース所有者のパスワード付与フロー

ネイティブアプリケーションに対してリソース所有者のパスワード付与（ROPG）フローの使用はお勧めしません。IEFTの「RFC 8252 OAuth 2.0 for Native Apps」の記事では、ネイティブアプリからのOAuth 2.0認可要求は外部のユーザーエージェント（主にユーザーのブラウザー）経由でのみ行われるべきであることが推奨されています。詳細については、「RFC 8252 Embedded User-Agents」を参照してください。

リソース所有者のパスワード付与（ROPG）の使用は、上記で説明したリダイレクトベースのオプションよりもセキュリティが劣ります。ROPG はレガシーシステム向けのみの使用が推奨されています。CLIに関して言えば、レガシープログラムをサポートする必要がある接続文字列のようなケースにのみ意味があります。

弊社が推奨するデバイスフローの代わりに、ネイティブアプリでROPGを使用しなければならない場合は、OIDC準拠のROPGエンドポイントを使用できます。