からめもぶろぐ。

SharePoint が得意なフレンズなんだね!すごーい!

Azure Active Directory のアプリの「Web アプリ/API」と「ネイティブ」の違いについて

Azure Active Directory でアプリケーション登録をするときに「Web アプリ/API」と「ネイティブ」を選択できますが、何が違うのか忘れてしまうので、自分用メモで残しておきます。

一般的なアプリの種類と使用するフローについての説明はこちらがわかりやすいです。

www.buildinsider.net

「ネイティブ」ではクライアント シークレットを発行できない

「Web アプリ/API」の場合はクライアント シークレットを作成できます。Azure Active Directory では [設定] - [API アクセス] - [キー] の項目です。

「ネイティブ」の場合はクライアント シークレットを作成することができません。

クライアント シークレットは秘匿化しなければなりませんが、「ネイティブ」に分類される Windows アプリやモバイル アプリの場合、クライアントにアプリケーションを展開する必要があるため、クライアント シークレットを安全に保持することができません。そのため、「ネイティブ」でアプリケーションを登録した場合は、そもそもクライアント シークレットを作成することができないようになっています。

実行できるフローに制限がある

RFC 6749 で定義されている OAuth フローには以下の種類があります。

Authorization Code Grant 認証後に認可サーバーに Authorization Code を発行してもらう認可フロー。
Implicit Grant 暗黙的に Access Token を取得する認可フロー。
Resource Owner Password Credentials Grant 認証情報としてユーザー名とパスワードを使用する認可フロー。
Client Credentials Grant バックグラウンドで動作するアプリケーション向けの認可フロー。

これらのうち、Client Credentials Grant (grant_type=client_credentials) については、クライアント シークレットが必須のため、使用することができません。Client Credentials Grant は「委任されたアクセス許可」ではなく「アプリケーションのアクセス許可」が使用できるフローですが、上記の理由により、「ネイティブ」では「アプリケーションのアクセス許可」を使用できないことになります。

Authorization Code Grant にも違いがあります。「Web アプリ/API」の場合は、アクセス トークンの要求 (/oauth2/token) でクライアント シークレットが必須になります。しかし「ネイティブ」の場合は、クライアント シークレットを指定しなくともアクセス トークンの取得が可能です。Windows アプリやモバイル アプリを作っていて、アクセス トークンの要求で失敗するときに、アプリケーションの種類を間違えている可能性がありますので、注意が必要です。