OAuth2-ユーザーの操作なしで認証
そのため、APIを介して外部アプリから自分のデータにアクセスしようとしています。 自分のデータにアクセスするだけで済みます。ユーザーのアカウントからデータを受信しようとしないため、ユーザーは何も承認する必要がありません。したがって、明らかにリダイレクトを回避する必要があります（これは、OAuthを調査すればするほど標準的なプロセスのようです...）
プロセスは/authorizeエンドポイントに到達し、コードが返されます。次に、そのコードをaccesstokenエンドポイントへのリクエストで提供します。これにより、APIを介して自分のアカウントにアクセスできるようになります。このプロセスはすべてのOAuthで標準であると95％確信していますが、そうでない場合に備えて詳細を提供すると考えました。
トークンのリクエストに入力するコードを取得するためにバックエンドで資格情報を提供して、すべてのユーザー操作を無効にするにはどうすればよいですか？私が使用しているAPIは、OAuthの使用を強制します。
あなたが説明しているoauth2グラントは Authorization Code Grant 。この認証方法は、ユーザーのリソースにアクセスしたいアプリケーションがユーザーの資格情報にアクセスできないように設計されていますnot。
したがって、この許可でユーザー資格情報を操作する方法を見つけた場合、それはハッキングと見なされます。
個々のユーザーにユーザー名とパスワードを入力させたくないが、一種の「システムアカウント」でAPIにアクセスしたい場合、これは使用すべきoauth付与ではありません。
あなたのために働くだろう複数の助成金があります。問題は、認証サーバーによってサポートされ、使用できるものはどれかということです。
この付与タイプは、リソース所有者の資格情報を取得できるクライアントに適しています。
しかしながら
リソース所有者のパスワード資格情報付与タイプは、リソース所有者がデバイスのオペレーティングシステムや特権の高いアプリケーションなどのクライアントと信頼関係にある場合に適しています。
この付与タイプは、ユーザーの資格情報を盗むために悪用される可能性があるため、利用できない可能性が非常に高くなります。
クライアントは、クライアントの資格情報のみを使用してアクセストークンを要求できます。
リソースがクライアントにどのように関連付けられているかは、oauth仕様の一部ではないため、プロバイダー固有です。
Oauth2についてもっと読みたい場合 ここ は良い記事です。
あなたが説明しているOauth 2の付与フローは、上記の回答が言うように、承認コードの付与フローです。そして、彼らが言うように、上記の2つの付与のいずれかを使用するオプションがある場合そのAPIを使用すると、これが最も簡単なソリューションです。
ただし、そうでない場合でも、「ユーザーの操作」を回避する方法はあります。 「ユーザーインタラクション」の意味は不明ですが、認証コードフローでは、通常、認証しようとしているAPIを呼び出すWebアプリにログインし、同意ページで同意することを意味します。例については、 https://dev.fitbit.com/docs/oauth2/#authorization-page を参照してください（Fitbitの場合はOAuth 2を実装しました:)）。同意ボタンをクリックするには、Seleniumなどの自動化されたWebブラウザーを使用する必要があります。次に、/ authorizeからの応答でコードをキャプチャし、アクセストークンエンドポイントにコードを送信できます。