Azure AD アプリケーションの Web アプリ/API とネイティブの違いについて
はじめに
Azure AD でアプリケーションを登録する際、Web アプリ/API と ネイティブ を選択できますが、両者の違いを解説します。
一般的なアプリの種類と使用するフローについては、以下のページが参考になります。
ネイティブではクライアント シークレットを発行できない
Web アプリ/API の場合はクライアント シークレットを作成できます。Azure AD では 設定 - API アクセス - キー の項目で設定します。
ネイティブ の場合はクライアント シークレットを作成できません。
クライアント シークレットは秘匿化する必要があります。しかし、ネイティブ に分類される Windows アプリやモバイル アプリの場合、クライアントにアプリケーションを配布する必要があるため、クライアント シークレットを安全に保持できません。そのため、ネイティブ でアプリケーションを登録した場合は、クライアント シークレットを作成できない仕様となっています。
実行できるフローに制限がある
RFC 6749 で定義されている OAuth フローには、以下の種類があります。
| 名前 | 説明 |
|---|---|
| Authorization Code Grant | 認証後に認可サーバーから Authorization Code を発行してもらう認可フロー |
| Implicit Grant | 暗黙的にアクセス トークンを取得する認可フロー |
| 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 アプリやモバイル アプリを開発していて、アクセス トークンの要求で失敗する場合は、アプリケーションの種類を誤って設定していないか確認してください。
おわりに
アプリケーションの種類によって Web アプリ/API と ネイティブ のいずれかを適切に選択する必要があります。セキュリティを確保するためにも、これらの違いを理解しておくことが重要です。
Discussion