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 アプリやモバイル アプリを作っていて、アクセス トークンの要求で失敗するときに、アプリケーションの種類を間違えている可能性がありますので、注意が必要です。
Discussion