- はじめに
- そもそも「委任されたアクセス許可」と「アプリケーションのアクセス許可」の違いは何か？
- 「アプリケーションのアクセス許可」のデメリット
- どうやって「委任のアクセス許可」を使うか
- Group.Read.Allの権限を使用した例
- 最後に
はじめに
Graph APIを使う方法を調査すると「アプリケーションのアクセス許可」で実装する例は多くみつかるのですが、「委任されたアクセス許可」の例はほとんどでてきません。
Graph API を「委任されたアクセス許可」で利用する方法を調べたので備忘録を兼ねて投稿します。
そもそも「委任されたアクセス許可」と「アプリケーションのアクセス許可」の違いは何か？
一言で違いを説明すると以下の通りです。
「委任されたアクセス許可」 ・・・ 指定したユーザーの権限でAPIを使用する
「アプリケーションのアクセス許可」 ・・・ AzureADアプリに設定した権限でAPIを使用する
このあたりをとても分かりやすい資料でまとめてくださっている方がいました。私はこちらを拝見して理解しました。ｱﾘｶﾞﾄｳｺﾞｻﾞｲﾏｽ (*ᴗˬᴗ)⁾⁾
jpo365ug.connpass.com
「アプリケーションのアクセス許可」のデメリット
アクセス許可の設定を「アプリケーションのアクセス許可」に限定してしまうことには以下のようなデメリットがあります。（要件によってはメリットもありますがこの投稿では割愛します）
APIからのレスポンスを実行ユーザーが製品側で付与されている権限でトリミングすることができない
上記と同じ理由で、実行側に許可する操作を細かく調整することができない。理由：トリミングができないのでリクエストの条件に一致するデータをすべて返す設定にせざるを得ない
「保護されたAPI」にあたるAPIを使う場合はAzureADアプリ単位でMSに利用申請を出す必要がある
どうやって「委任のアクセス許可」を使うか
以下の3つのステップで実現します
- AzureADアプリを登録する
- 作業端末に「MSAL.PS」モジュールをインストールする
- PowerShellでAPIを呼び出す過程でアクセストークンを使用する
手順1: AzureADアプリを登録する
AzureADアプリの登録を行います。
ここでは例として以下の2つのアクセス許可を「委任されたアクセス許可」で付与します。
・User.Read.All
・Group.Read.All
AzureADポータル開いて「アプリの登録」画面で「新規登録」をクリックします。
「名前」欄でAzureADアプリの名前を入力します。任意の文字列を大丈夫です。わかりやすい名前にしましょう。
「サポートされているアカウントの種類」で誰がAPIが使用できる範囲を指定します。テナント外から利用させる要件がなければ、一番上にある「この組織ディレクトリのみ～」を指定してください。
「リダイレクトURL」は入力は不要です。
ここまで入力したら画面最下部の「登録」をクリックします。
「概要」画面を開きます。以下の2つのIDをコピーしてメモにひかえます。
アプリケーション（クライアント）ID
ディレクトリ（テナント）ID
「認証」画面を開きます。「プラットフォームを追加」をクリックします。
「モバイル アプリケーションとデスクトップ アプリケーション」をクリックします。
「リダイレクトURL」にある「msal～」のチェックボックスをオンにします。
画面最下部の「構成」をクリックします。
「クリックボードにコピー」をクリックして、リダイレクトURLをメモにひかえます。
「APIのアクセス許可」画面を開きます。
既定で付与されていた「User.Read」は使わないので削除します。
まずは、User.Read.Allのアクセス許可を付与します。
「アクセス許可の追加」をクリックします。
「Microsoft Graph」をクリックします。
「委任されたアクセス許可」をクリックします。
付与したいアクセス許可（ここでは User.Read.All）を検索ボックスに入力します。画面下部に表示されたアクセス許可のうち、目的のもの（ここでは User）をクリックして開きます。
付与したいアクセス許可のチェックボックスをオンにします。画面最下部の「アクセス許可の追加」をクリックします。
これで、User.Read.Allのアクセス許可を付与できました。
次に、Group.Read.Allのアクセス許可を付与します。
「アクセス許可の追加」をクリックします。
「Microsoft Graph」をクリックします。
「委任されたアクセス許可」をクリックします。
付与したいアクセス許可（ここでは Group.Read.All）を検索ボックスに入力します。画面下部に表示されたアクセス許可のうち、目的のもの（ここでは Group）をクリックして開きます。
付与したいアクセス許可のチェックボックスをオンにします。画面最下部の「アクセス許可の追加」をクリックします。
「（テナント名）に管理者の同意を与えます」をクリックします。
「管理者の同意の確認を与えます」というメッセージが表示されたら「はい」をクリックします。
アクセス許可の「状態」欄に「(テナント名) に付与されました」と表示されたことを確認する。
これでAzureADアプリの作成は以上です。
手順2: 作業端末に「MSAL.PS」モジュールをインストールする
作業端末でPowerShellを管理者権限で起動します。
以下のコマンドを実行します。
作業端末に「MSAL.PS」モジュールをインストールする
Install-Module -Name MSAL.PS
これでモジュールのインストールは以上です。
手順3: PowerShellでAPIを呼び出す過程でアクセストークンを使用する
作成したAzureADアプリを使って、PowerShellからAPIを呼び出します。
以下はスクリプトの例を示します。以下の3点はメモにひかえた内容に置き換えてください。
- アプリケーション（クライアント）ID
- ディレクトリ（テナント）ID
- リダイレクトURL
またこの例では、付与したアクセス許可のうちUser.Read.Allを使用します。
Group.Read.Allの権限を使用した例については後述します。
スクリプトの例：AzureAD上のすべてのユーザーを取得
#------------------------------------------------- #入力情報 #------------------------------------------------- #テナントのID $tenantID = "（メモにひかえたID）" #AzureADアプリ $clientID = "（メモにひかえたID）" #MSALのリダイレクトURL $MSALRedirectUri = "（メモにひかえたリダイレクトURL）" #------------------------------------------------- #認証情報を取得 #------------------------------------------------- #トークンを取得 $token = Get-MsalToken ` -TenantId $tenantID ` -ClientId $clientID ` -RedirectUri $MSALRedirectUri ` -Interactive $headerParams = @{ 'Authorization' = "bearer $($token.AccessToken)" } #------------------------------------------------- #ユーザー情報を取得 #------------------------------------------------- $url = "https://graph.microsoft.com/v1.0/users/" $responseFromAPI = Invoke-RestMethod ` -uri $url ` -Method Get ` -Headers $headerParams $users = @() $users += $responseFromAPI.value $pages = $responseFromAPI.'@odata.nextLink' while([string]::IsNullOrEmpty($pages) -eq $false) { $addtional = Invoke-RestMethod ` -uri $pages ` -Method Get ` -Headers $headerParams $users += $addtional.value $pages = $addtional."@odata.nextLink" }
実行すると、認証情報の入力を求められます。
APIを呼び出すユーザーのIDとパスワードを入力します。
処理が完了しました。
期待した通りレスポンスがかえってきたことを確認します。
$users | select UserPrincipalName
期待する結果は以下の通りです。
Group.Read.Allの権限を使用した例
Group.Read.Allの権限を使用した例をご紹介します。
User.Read.AllとGroup.Read.Allの権限があると、下記の記事に記載しているMicrosoft Teamsのいいねを一覧取得することができます。
下記の記事では「アプリケーションのアクセス許可」を記載しましたが、「委任されたアクセス許可」を使っても実現することができます。
もちろん、ソースコードのほうも手直しをする必要がありますが、この投稿に例として記載しましたソースコードをみていただければ直す箇所はわかってもらえるかと思います。読み比べてみてください。
繰り返しになりますが、「委任されたアクセス許可」を使用した方法であれば以下のメリットがあります。
- 取得できるデータの対象を実行ユーザーがアクセスできる範囲に絞ることができる。（つまり、実行ユーザーがメンバに含まれていないチームのデータへのアクセスはブロックできる）
- 「保護されたAPI」ではないため、MSに申請をする必要がない。
