2017-09-19 3 views
1

複数のテナントのユーザ受信ボックスでアクションを実行できるデーモンアプリを開発中です。テナントの管理者がアプリに必要な権限を与えると、そのテナントのユーザの受信トレイにアクセスできるようになります。私は今、次のことをしています。Azure AD v2.0エンドポイントからトークンを取得するときにサービス/デーモンアプリが 'tenant-id'の代わりに 'common'を使用することができます。

  1. テナント(例えばmyutils.onmcirosoft.com)から管理

    https://login.microsoftonline.com/common/adminconsent?client_id={client-id}&redirect_uri=https%3A%2F%2Fredirect.test.com

  2. グローバル管理者から同意を得る必要な許可を与えます。

  3. は、それがアクセストークンを与える代わりにtenant-id

    curl -X POST _https://login.microsoftonline.com/common/oauth2/v2.0/token --data "grant_type=client_credentials&client_id={client-id}&client_secret={clientsecret}&scope=https://graph.microsoft.com/.default

    commonを使用してアクセストークンを取得します。私は交換する場合には、ステップ3では HTTP/1.1 404 Not Found Cache-Control: private Transfer-Encoding: chunked Content-Type: text/plain request-id: e602ada7-6efd-4e18-a979-63c02b9f3c76 client-request-id: e602ada7-6efd-4e18-a979-63c02b9f3c76 x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"West US","Slice":"SliceB","ScaleUnit":"000","Host":"AGSFE_IN_22","ADSiteName":"WST"}} Duration: 1537.3097 Date: Tue, 19 Sep 2017 09:31:08 GMT

  • ステップカールリクエストの上3.

    curl -X GET -H "Authorization: Bearer <token>" https://graph.microsoft.com/v1.0/users/[email protected]/messages

    で得られたトークンを使用して[email protected]のアクセスメッセージは、次のよう404応答を与えますcommontenant-idmyutils.onmicrosoft.comとなっています。

    commonはAzure AD v2.0エンドポイントでサポートされていますか? Thisリンクでは、v1エンドポイントではcommonがサポートされていません。 v2.0エンドポイントでも同じですか?

  • +0

    たとえば、次のようにトークンを検査しようとしましたか? https://jwt.io?私はこれが不可能ではないことを100%確信しているわけではありませんが、私の意見ではトークンの共通点を呼び出すのは意味がありません。 Microsoft Graph APIにアクセスすると、テナントのデータは返されますか?あなたのアプリがシングルテナントの場合、答えは簡単です。しかし、マルチテナントの場合、テナントIDの指定は必須です。 – juunas

    +0

    こんにちは、私のアプリはマルチテナントです。私が「共通」で試してみたかった理由は、それが動作すれば、同じトークンで複数のテナントにリクエストを送信できます。それがなければ、私はテナントごとにトークンを個別に取得する必要があります。 https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-credsページは、動作することを示唆しています。ここの例では、「adminconsent」と「共通」を使用しています。更新する必要があります。 – Dhana

    +0

    管理者の同意がある場合、それは承認URLであり、トークンURLではありません。 – juunas

    答えて

    0

    Nan Yoの回答を拡張すると、tenant-idが必要な理由は、Graph API自体がマルチテナントであるためです。

    tenant-idが指定されていないと、Graphはあなたの通話をルーティングするテナントを知る方法がありません。たとえば、/usersはユーザーリストを返しますが、tenant-idがないと、ユーザーを引き出すテナントを特定する方法がありません。

    authorization_codeまたはimplicitグラントを使用すると、ユーザーの資格情報を使用して、どのテナント呼び出しをルーティングするかを決定します。 client_credentialsでは、これらのルーティングキューを取得するための資格情報がありません。

    ただし、管理者の同意のもとでテナントIDを確認することはできます。 admin_consentの結果と共に、tenantも返されます。マルチテナントサービスの場合、Graphを呼び出す前にトークンを取得するときに使用するために、そのIDを格納する必要があります。

    +0

    こんにちはマーク、私はPOST操作のみを行っています(ステップ3)。私はこのページの「https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds」の手順に従っています。それは認可とトークンを取得するために「共通」を使用します。しかし、メッセージを取得するためにトークンを使用している間、私は '404'応答を受け取りました。私はページを更新する必要があると感じています。マルチテナントデーモンのアプリケーションでは「common」のような表記はサポートされていません – Dhana

    +0

    ありがとうございます。今はっきりしています。 – Dhana

    1

    Azure AD V2.0でクライアントクレデンシャルフローを使用する場合は、トークンを適用する実際のテナントを指定する必要があります。そうしないと、アクセストークンを取得しても、アクセストークンにアプリケーションロールが含まれていないことがわかります。あるテナントからアクセストークンが発行され、そのテナントのリソースにアクセスする可能性があります.1つのアクセストークンを使用してマルチテナントのリソースを照会することはできません。

    トークンを取得してください/common/oauth/v2.0/tokenエンドポイントから、テナントIDの/{tenent-id}/oauth2/v2.0/tokenエンドポイントを使用してください。

    詳細については、hereをクリックしてください。

    +0

    答えとリンクをありがとう。今はっきりしています。 – Dhana

    関連する問題