3
バックエンドアプリケーションからadal4j（バージョン1.2.0）を使用してPowerBI REST APIを使用してレポートを埋め込むアクセストークンを取得しています（具体的には、GenerateTokenメソッド）。 Azureにネイティブアプリを登録し、必要な権限を与えました。クライアントの資格情報を使用して、Azure ADからネイティブアプリ登録（PowerBI）のアクセストークンを取得する
AuthenticationContext ac = new AuthenticationContext("https://login.windows.net/TENANT_ID/oauth2/authorize", false, es);
Future<AuthenticationResult> f = ac.acquireToken("https://analysis.windows.net/powerbi/api", CLIENT_ID, USERNAME, PASSWORD, null);
をそして成功したAPIへの認証にトークンを使用し、最終的に埋め込まれたレポートを示しています。私は次のようにユーザー名/パスワードの組み合わせを使用してアクセストークンを取得することができます。しかし、私のケースでは、もちろん、ユーザーアカウントの代わりにクライアントの資格情報（クライアントID、クライアントの秘密）を使用したいと思います。
AuthenticationContext("https://login.windows.net/TENANT_ID/oauth2/authorize", false, es);
ClientCredential cc = new ClientCredential(CLIENT_ID, CLIENT_SECRET);
Future<AuthenticationResult> f = ac.acquireToken("https://analysis.windows.net/powerbi/api", cc,null);
クライアントIDが登録ネイティブアプリのアプリケーションIDであり、クライアントの秘密は、アプリケーションにキーを追加することによって定義されます。次のように私は再びトークンを取得することができます。 もう一度トークンを取得しましたが、今度はそれをAPIに対して認証するのにもう使用できません（HTTP 403、これ以上の詳細はありません）。
私の質問は、最初はうまくいくはずですが、Azureやadal4jを使って技術情報が欠落していますか？
編集：以下は委任されたアプリのアクセス許可のスクリーンショットです。
取得したトークンを確認しましたか？ jwt.ioのようなサイトを使って、その内容を調べることができます。しかし、PBI REST APIは以前に作業したときから変更されていない限り、委任された呼び出しのみを許可しました。つまり、ユーザーのコンテキストで実行する必要があります。 – juunas
@ juunasチップをありがとう。私はすでにトークンのタイプと有効期限が認証結果からOKであることを確認し、jwt.ioは両方のトークンが有効であることを示しています。ユーザー名とパスワードの組み合わせで生成されたものは、ペイロードにはるかに多くの情報が含まれていますが、具体的にはユーザーアカウントに関するものです。これはおそらく委任された呼び出しのみが許可されているというあなたの主張を支持するでしょう。これについての見積もりを取ろうとする必要がありますが、それが本当である場合は、パスワードが失効しない専用アカウントを作成するオプションがあると思いますが、少し残念です。 –
アプリケーションのみの認証の結果、アプリに与えられた役割がいくつかある場合は、トークンにロールが含まれている必要があります（アプリの権限とも呼ばれます）。委任された呼び出しには、トークンに "スコープ"（scpの主張）があります。 – juunas