問題タブ [rest-security]

他の人がこれをどのように解決したかについての情報を見つけることができなかったので、あなたが私を助けてくれるかもしれません.

私が持っているもの

OpenID Connect を使用して保護された REST API を使用した複数のサービス。サービス間の接続は正常に機能します。現在、複数の開発者がいて、迅速な分析とテストのためにローカル スクリプト (Python、R、Bash など) を作成して実行する必要があります。

私が欲しいもの

開発者ができるだけ簡単にサービスを利用できるようにしたいと考えていますが、セキュリティ上の懸念も考慮しています。

私が試したこと

スクリプト自体をクライアントとして定義しました。そのため、OIDC 製品でパブリック クライアントを作成しました。これは、「開発者スクリプト」のような名前です。oauth ダンスを処理するライブラリを使用して、前述のクライアントとして接続するスクリプトを実行できます。最初に、ブラウザーがポップアップしてユーザーに認証を要求し、クライアントがユーザーに代わって REST API を使用することを承認します。その後、トークンがキャッシュされるので、そのスクリプトの作業を簡単に続行できます。

この単純化された図は、今説明したことを要約しようとしています

それは完全にうまく機能し、セキュリティに関しては、たとえば基本認証の場合のように、資格情報がローカルコンピューターに保存されないことを嬉しく思います。さらに、さまざまなサービスへのアクセスをユーザー レベルで制御できます。

私を納得させなかった他のアイデア：

• すべての Web サービスには、スクリプトによってクライアントとして使用できるパブリック クライアントもあります (そのため、スクリプトはクライアントとして定義されなくなりました)。
• トークンの生成は別の場所で行われ、開発者は生成されたアクセス/リフレッシュ トークンをスクリプトに追加するだけです。

私の問題

現在のソリューションで気になるのは、そのクライアントの定義です。説明されているケースでは、すべての開発者がすべてのスクリプトで使用する汎用クライアントか、ローカル スクリプトを記述したいすべての開発者向けの新しいクライアントのいずれかになります。後者はオーバーヘッドが大きいようですが、前者はセキュリティ上の問題でしょうか?

最後に質問をします。説明したユース ケースで既知のベスト プラクティスはありますか?

編集:
[Martin Fowler](https://martinfowler.com/articles/command-line-google.html) による小さな記事を見つけました。彼は基本的に、ローカル スクリプトに使用するトークンを受け取る方法を説明しています。しかし、彼の場合、彼はそれを特定のユース ケースに使用しており、一般のクライアントとしてではありません。残念ながら、それは私の答えにはあまり貢献しません。