pythonのmsalでConfidentialClientApplicationとPublicClientApplicationの違い、PublicClientApplicationの簡単な実装例

Last updated at 2025-06-16Posted at 2025-06-16

はじめに

この記事ではConfidential/Public Client Applicationの違いについて簡単に説明した後で、msalでPublicClientApplicationの簡単な設定例をお伝えしようと思います。
実はPublic Client Applicationの設定する際に、なかなかうまくいかなかったので、同じように理解に苦しんだり、つまづいている方の助けになれば幸いと思い記事にさせていただきました。

Confidential Client Application と Public Client Application の違い

MSAL における Public Client Application と Confidential Client Application のどちらを選ぶかは、アプリケーションの運用環境や求められるセキュリティ要件によって決まります。

Public Client Application は、ユーザーのデバイス上で直接認証が行われるアプリケーション向けです。実装はシンプルで、モバイル・デスクトップ・SPA などユーザー向けのアプリケーションに最適ですが、バックグラウンド処理やサーバー側の認証には制約があります。
Confidential Client Application は、サーバー内で安全に機密情報を保持し、ユーザーの介入なしでトークンを取得できるため、セキュリティ面や自動処理が要求されるサーバーサイドのアプリケーション（ウェブアプリケーション、Web API、サービス/デーモン）向けとなります。ただし、実装や運用がやや複雑になる点に注意が必要です。

1. 基本的な定義

Public Client Application

概要:
Public Client Application はデスクトップ、モバイル、シングルページアプリケーション（SPA）など、ユーザーのデバイス上で動作するアプリケーションです。
ユーザーが直接操作する環境で実行されるため、ソースコードやバイナリから機密情報を隠すことが難しく、クライアントシークレットや証明書などの機密情報を保持しません。
主な認証フロー:
ユーザーのインタラクティブなログインや、Device Code Flow のようにユーザーの操作を伴う認証に対応しています。直接ユーザーの資格情報を使ってトークンを取得し、Web API などにアクセスする用途に向いています。

ログイン機能を備えた一般的なアプリケーションで使われると考えるのが分かりやすいかもです。

Confidential Client Application

概要:
Confidential Client Application は主にサーバーサイドで実行されるウェブアプリケーション、Web API、サービス/デーモン（バックエンドプロセス）などが該当します。これらのアプリケーションは、安全なサーバー環境内で実行されるため、クライアントシークレットや証明書といった機密情報を安全に管理でき、アプリケーション自身の身元を証明することが可能です。
主な認証フロー:
ユーザーの介入がなくても、クライアントクレデンシャルフロー（Client Credentials Flow）や認可コードグラントフローなどを用いて、バックグラウンドでトークンを取得することができます。

ユーザーによるログインのないアプリケーションですね。アプリケーション自体に証明書を持っていてリソースを使用することができます。
そんなのあるの？と思うかもしれませんが、世の中のアプリケーションはユーザーに紐づけて利用されるものだけではありません。

Microsoft Learn - Public and confidential client apps (MSAL)

2. 機能の比較

以下の表は、Public Client と Confidential Client の主要な機能や特性を比較したものです。

比較項目	Public Client Application	Confidential Client Application
展開環境	デスクトップ、モバイル、シングルページアプリ（SPA）、ブラウザベース	ウェブアプリケーション、Web API、サービス/デーモンアプリ
機密情報の保持	クライアントシークレットや証明書を持たず、外部に漏らすリスクが低い	サーバー上で安心して保持可能。アプリの身元を確実に証明するための情報がある
認証フロー	ユーザーのインタラクティブログインや Device Code Flow 等	クライアントクレデンシャルフロー、認可コードグラントフローなど、様々なフローに対応
セキュリティの観点	ユーザーのデバイス上で実行されるため、設計上機密情報をもたせないことで安全性を確保	サーバー内で安全に管理できるため、より高いセキュリティレベルを実現可能
実装の複雑さ	実装がシンプルで、コード中に秘密情報を含める必要がない	機密情報の管理や証明書の設定など、設定や開発がやや複雑になる

3. メリット・デメリット

Public Client Application

メリット

シンプルな実装:
機密情報（クライアントシークレットなど）を管理する必要がないため、実装が比較的簡単です。
利用環境が柔軟:
ユーザーデバイス上で直接動作するため、モバイルアプリやデスクトップアプリ、ブラウザでの利用に適しています。
セキュリティリスクが限定的:
秘密情報を持たないため、ソースコードやアプリケーションが漏れても大きな影響を及ぼさないケースがほとんどです。

デメリット

認証フローの限界:
ユーザー認証を前提とするため、ユーザーの介入が必要となり、バックグラウンド処理や自動認証が難しい場合があります。
サーバーサイド処理には不向き:
セキュリティ上、サーバー側で機密情報を保持できないため、サーバー間の通信や自動処理にはあまり適用できません。

Confidential Client Application

メリット

高いセキュリティ:
サーバー環境で実行されるため、クライアントシークレットや証明書などの機密情報を安全に保管し、厳格な認証を行うことができます。
自動化やバックグラウンド処理に最適:
ユーザーの介入なしに認証が行えるため、サービスやデーモン（バックエンドプロセス）での利用に適しています。
柔軟な認証フロー:
クライアントクレデンシャルフローなど、多様な認証方法を利用できるため、用途に応じた高度な認証処理が可能です。

デメリット

実装の複雑さ:
機密情報の安全な管理が求められるため、設定や運用が複雑になります。
運用環境の制約:
サーバー側でのみ運用が可能なため、ユーザーのローカルデバイス上での認証処理やシンプルなクライアント用途には不向きです。

Public Client Applicationの実装例

Confidential Client Application は以前の記事でmsalでアクセストークンを取得を書いているので参考にしてください。
今回はPulic Client Applicationです。

PublicClientApplication

以下が簡単なソースコードです

import msal

CLIENT_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
TENANT_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}"

# 利用する API のスコープを指定
SCOPES = ["User.Read"]

# PublicClientApplication のインスタンスを作成
app = msal.PublicClientApplication(client_id=CLIENT_ID, authority=AUTHORITY)

クライアントIDとテナントIDはどこで取得するのでしょうか？

答えはAzure Portalです

アプリの登録

azureポータルからアプリの登録を行います。
はじめてazureポータルを触った時は、アプリの登録という概念自体が分からす、頭が混乱したものです。

スマホアプリやウェブサイト、デスクトップアプリを作るとします。
そのアプリでユーザーが Microsoft のアカウントでログインできるようにしたい場合、Azure AD がその「身元」を保障し、ログイン情報の管理を行います。
しかし、まず Azure AD にそのアプリがどんなアプリなのかを伝える必要があります。これが「アプリの登録」です。

アプリの登録をすると、このアプリケーションID(クライアントID)を使用して、Azureのリソースを使用することができるようになります。
テナントIDはこのAzureを管理しているIDです。テナント内の〇〇というアプリケーションですという証明になるわけです。

しかしこれだけ証明するのは安全ではないので、そこに認証を追加します。
このとき、アプリケーション自体にシークレットキーを付与して認証するものと、アプリケーションを利用するユーザーによる認証のいずれかを使用するわけです。

さて設定をすると以下のようにクライアントIDとテナントをIDを取得できます。

実装？

さてこれでさきほどのコードを実装してみましょう

import msal

CLIENT_ID = "取得したクライアントID"
TENANT_ID = "取得したテナントID"
AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}"

# 利用する API のスコープを指定
SCOPES = ["User.Read"]

# PublicClientApplication のインスタンスを作成
app = msal.PublicClientApplication(client_id=CLIENT_ID, authority=AUTHORITY)

# キャッシュ内に保存されたアカウントがあればサイレントにトークン取得を試みる
accounts = app.get_accounts()
if accounts:
    result = app.acquire_token_silent(scopes=SCOPES, account=accounts[0])
else:
    result = None
    # キャッシュにトークンがない、もしくはサイレント取得に失敗した場合はインタラクティブにログイン
    print("インタラクティブなログインが必要です。ブラウザが起動しますので、ログインしてください。")
    result = app.acquire_token_interactive(scopes=SCOPES)

    # print("initiate_flow、ログインしてください。")
    # flow = app.initiate_device_flow(scopes=SCOPES)
    # result = app.acquire_token_by_device_flow(flow)

pprint(f"取得した結果: {result}")

# 結果の判定
if "access_token" in result:
    print("アクセストークンの取得に成功しました:")
    print(result["access_token"])
else:
    print("アクセストークンの取得に失敗しました:")
    print("エラー:", result.get("error"))
    print("詳細:", result.get("error_description"))