web-dev-qa-db-ja.com

ユーザー/パスワードを使用せずにMicrosoft Graph GraphServiceClientを作成する

Microsoft Graph APIを使用してMicrosoft Graphに接続するコンソールアプリケーションを作成しています（ https://github.com/microsoftgraph/console-csharp-connect-sample を参照）。すべてが正常に機能していますが、[アカウントにサインイン]ウィンドウに表示される資格情報を手動で入力しなくても、ユーザーを認証できる方法（すでにユーザー/パスワードがわかっている場合）があるのでしょうか。デスクトップ。基本的にはアプリケーションを無人で実行するという考え方なので、アプリケーションの起動時にユーザーが資格情報を入力する必要はありません。この件に関する関連情報が見つかりません。それは可能ですか？

編集

@DanSilverがユーザーなしでアクセスすることについて投稿したリンクをたどった後、そのリンクで提案されているサンプルを試してみました（ https://github.com/Azure-Samples/active-directory-dotnet-daemon-v2 =）。これはユーザーに認証を強制するMVCアプリケーションですが（正確には回避したかったのですが）、コンソールアプリケーションでそのサンプルの認証コードの一部を使用することができました。 https://login.microsoftonline.com/myTenantId/adminconsent へのリクエストを通じてアプリケーションに手動で承認を与えた後、ユーザーの操作なしでGraphに接続するGraphServiceClientをコンソールアプリに作成できます。だから私は答えを有効としてマークします。誰かが同じ状況にある場合に備えて、GraphServiceclientは次のように作成されます。

GraphServiceClient graphServiceClientApplication = new GraphServiceClient("https://graph.Microsoft.com/v1.0", new DelegateAuthenticationProvider(
    async (requestMessage) =>
    {
        string clientId = "yourClientApplicationId";
        string authorityFormat = "https://login.microsoftonline.com/{0}/v2.0";
        string tenantId = "yourTenantId";
        string msGraphScope = "https://graph.Microsoft.com/.default";
        string redirectUri = "msalXXXXXX://auth"; // Custom Redirect URI asigned in the Application Registration Portal in the native Application Platform
        string clientSecret = "passwordGenerated"; 
        ConfidentialClientApplication daemonClient = new ConfidentialClientApplication(clientId, String.Format(authorityFormat, tenantId), redirectUri, new ClientCredential(clientSecret), null, new TokenCache());
        AuthenticationResult authResult = await daemonClient.AcquireTokenForClientAsync(new string[] { msGraphScope });
        string token = authResult.AccessToken;
        requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", token);                            
    }                
));
c#microsoft-graph
10
Ada

1つのアイデアは、「アプリのみ」の承認フローを使用することです。これは、ユーザー認証なしで長時間実行アプリがMicrosoft Graphにアクセスできるという考え方です。主な違いは、特定のユーザーにアクセスを許可するアクセストークンの代わりに、事前に同意したリソースへのアクセスをアプリに許可することです。ユーザーログインダイアログはなく、プログラムでアクセストークンをフェッチしてGraph APIを呼び出すことができます。

これらのトークンが特定のユーザー向けではないことを繰り返し説明するには、「 https://graph.Microsoft.com/v1.0/me 」へのGETリクエストを行うことを検討してください。アクセストークンは特定のユーザー向けではなく、「私」は何も意味しないため、これはエラーを返します。リクエストは、「graph.Microsoft.com/users/[email protected]のような」完全なユーザーIDで送信する必要があります。

これに関する詳細情報は ユーザーなしでアクセスを取得 のドキュメントページにあります。

別のアイデアは、ユーザーがアプリを初めて使用するときに認証を行い、次に更新トークンを保存することです。これらのトークンはより長く存続し（数か月間IIRC）、アプリを実行するたびにユーザーの同意を求める必要はありません。更新トークンは、60分間有効なアクセストークンと交換でき、ユーザーに代わってGraph APIを呼び出すために使用できます。

更新トークンの詳細： https://developer.Microsoft.com/en-us/graph/docs/concepts/auth_v2_user#5-use-the-refresh-token-to-get-a-new-アクセストークン

4
Alex

昨日この問題に遭遇したので、ここに戻って共有したかったのですが、自分のアプリケーションにメールボックスの読み取り/書き込みアクセス権を付与するという考えは...組織全体のすべての人のメールボックスに...私のニーズのためのトップ。 （そして、登録されたアプリに委任されたアクセス許可ではなく、アプリケーションレベルのアクセス許可を付与することについて話し始めると、まさにそれが起こります）。

これは簡単な使用例です。私は、従来のADサービスアカウントを使用して共有メールボックスからの電子メールの送信を自動化する必要のある夜間プロセスを持っていました。

ありがたいことに、彼らはパスワードを排除するために行進中ですが（笑）... Microsoftの誰かが私の使用例をまだ認識しています。AzureADにはアップルツーアップルの選択肢がありません。私たちが仕事を成し遂げるために頼ることができる拡張メソッドがまだあります：

private AuthenticationContext authContext = null;
authContext = new AuthenticationContext("https://login.microsoftonline.com/ourmail.onmicrosoft.com", 
                new TokenCache());
result = authContext.AcquireTokenAsync("https://graph.Microsoft.com/", 
                "12345678-1234-1234-1234-1234567890", 
                new UserPasswordCredential( 
                    Environment.GetEnvironmentVariable("UID", EnvironmentVariableTarget.User), 
                    Environment.GetEnvironmentVariable("UPD", EnvironmentVariableTarget.User) 
                )).Result;

これらのGetEnvironmentVariable呼び出しをユーザー名（UID）とパスワード（UPD）に置き換えることができます。サービスアカウントの環境変数にそれらを詰め込むだけなので、ソース管理に何もチェックする必要はありませんでした。

AcquireTokenAsyncは、Microsoft.IdentityModel.Clients.ActiveDirectory名前空間から利用可能な拡張メソッドです。そこから、GraphClientを起動するのは簡単なビジネスです。

        string sToken = result.AccessToken;
        Microsoft.Graph.GraphServiceClient oGraphClient = new GraphServiceClient(
                    new DelegateAuthenticationProvider((requestMessage) => {
                        requestMessage
                            .Headers
                            .Authorization = new AuthenticationHeaderValue("bearer", sToken);
            return Task.FromResult(0);
        }));

魔法の最後のビットは、Azure ADで作成したアプリケーション登録にこれらのアクセス許可を追加することでした（ここでGUIDの由来）。アプリケーションはパブリッククライアントとして定義されています（ラジオボタンがあります）これは認証タブの下部にあります）次の5つのデリゲートされたアクセス許可（アプリケーションのアクセス許可ではありません）を追加しました：

Microsoftグラフ
1。 Mail.ReadWrite.Shared
2。 Mail.Send.Shared
3。 User.Read
4。 Eメール
5。 openid

組織ではユーザーの同意が実際にブロックされているため、別の権限管理者がアプリケーション定義を確認してから、それらの権限を管理者レベルで付与する必要がありましたが、そうするとすべてが点灯し、必要に応じて機能しました。サービスアカウントによるアクセス制限アクセスの実際のセキュリティはOffice 365で管理され、Azure ADでは管理されません。

2
Frog Pr1nce