0
私はそれをサポートする2つの方法があることがわかったので、https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-credsともう1つは、アプリケーションIDによって顧客のオフィス365リソースにアクセスするデーモンサービスを書きたいhttps://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-certificate-credentialsです。私はそれらの間に何が違うのか、デーモンサービスを実装するためのビートの解決策を知りたい。OAuth 2.0クライアントの資格情報フローと証明書の資格情報の相違点
おかげ
感謝を。あなたの意見に基づいて、client_credentialだけを使用できるシナリオはありますか？私は1つの問題に遭遇するので、ここではプロトコルに基づいたサービスアクセストークンで要求サブスクリプションが失敗しました。https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols -oauth-client-creds＃get-a-token＃戻りトークンがreason = "アクセストークンは、このアプリケーションのアクセスを許可するには弱すぎる認証方法を使用して取得されました。 "; error_category =" invalid_token " – zero
サービスはトークンを取得するためにより多くのセキュリティメソッドを必要とするようです。たとえば、証明書を使用します（[here]（https://blogs.msdn.microsoft.com/iwilliams/2016/09/12/what-is-aobo/）を参照してください）。 –
ええ、私は同じアイディアを持っていたので、証明書を作成してマニフェストファイルを変更しましたが、アクセストークンでサブスクリプションを呼び出すときにも失敗しました。 – zero