💻

Azure AD アプリケーションの Web アプリ/API とネイティブの違いについて

2022/01/01に公開

はじめに

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

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

https://www.buildinsider.net/enterprise/openid/oauth20

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

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