【ITニュース解説】Authentication με Microsoft Entra ID σε ASP.NET Core

現代の企業向けアプリケーションにおいて、ユーザーの認証の仕組みは大きく変化している。かつては、ウェブアプリケーション自体がユーザー名とパスワードを受け取り、その正当性を検証していたが、今日ではその方法は主流ではない。特にASP.NET Coreのような最新のアプリケーション開発では、Microsoft Entra IDのような専門的なサービスが認証の中心的な役割を担うようになっている。

この新しい方式では、アプリケーションはユーザーのパスワードを直接知ることも、保管することも一切ない。認証という重要な責任は、Microsoft Entra IDという「Identity Provider（アイデンティティプロバイダー）」に完全に委ねられる。これにより、アプリケーションの設計思想は根本的に変わる。アプリケーションはもはや、「ユーザー名とパスワードを教えてくれ、私があなたの身元を確認する」とは言わず、代わりに「Microsoft Entra IDよ、このユーザーが本当に本人であることを確認し、その身元情報を私に教えてほしい」と依頼するようになる。これが、今日のエンタープライズ認証基盤の基礎となっている考え方である。

Microsoft Entra IDは、ユーザーの「身元」を保証する専門家、すなわちIdentity Providerとして機能する。このサービスは、ユーザーの身元情報や、アプリケーションとの信頼関係を管理し、「セキュリティトークン」と呼ばれる特別なデジタル証明書を発行する役割を担う。このセキュリティトークンが、アプリケーションやAPIがユーザーを信頼するための鍵となる。Microsoft自身も、Entra IDを「認証サーバーであり、アイデンティティプロバイダーであり、ID管理、信頼関係の構築、そしてトークンの発行をすべて行うもの」と説明している。

ここで、しばしば混同されがちな二つの重要な概念、「認証（Authentication）」と「認可（Authorization）」について明確に理解しておく必要がある。この二つは関連しているが、その意味は全く異なる。

認証とは、簡単に言えば「あなたは誰ですか？」という問いに答えるプロセスだ。ユーザーが自分の身元を証明し、アプリケーションがそれを受け入れることを指す。例えば、ウェブサイトでメールアドレスとパスワードを入力してログインする行為がこれにあたる。ユーザーが「nikos@company.com」として無事にログインできた場合、これが認証が成功した状態である。

一方、認可とは「あなたは何をすることができますか？」という問いに答えるプロセスを意味する。ユーザーの身元が確認された後で、そのユーザーが特定のアクション（例えば、API経由でシステム内の特定のデータを削除する）を実行する権限を持っているかどうかを判断することである。たとえ「nikos@company.com」として認証されたとしても、そのユーザーがシステム内の「DELETE /api/users/15」という操作を実行する権限を持っているとは限らない。認証はログインを可能にするが、認可はその後の操作の範囲を決定する。

この認証と認可の明確な区別は、Microsoftのアイデンティティプラットフォームにおいても非常に重要である。ユーザーの身元を証明するために「IDトークン」が使われ、保護されたリソースやAPIへのアクセス権限を証明するために「アクセストークン」が使われる。

IDトークンは、ユーザーがMicrosoftアカウントを使ってアプリケーションにサインインした際に、Microsoftのプラットフォームから発行される「身分証明書」のようなものだ。アプリケーションはこのトークンを受け取ると、その中身（「クレーム」と呼ばれるユーザー情報）を読み取る。そこには、ユーザーの名前（name）、優先ユーザー名（preferred_username）、そして一意のオブジェクトID（oid）などが含まれている。アプリケーションはこれらの情報を使って、「こんにちは、〇〇さん」といった形でユーザーを歓迎したり、画面にユーザー名を表示したりする。重要な注意点として、このIDトークンは、アプリケーションが外部のAPIからデータを取得するために使われるべきではない。それはあくまで、アプリケーションがユーザー自身の身元を把握するためのものである。

アクセストークンは、アプリケーションが保護された外部リソース（例えば、Microsoft Graph API）からデータを取得したい場合に、「鍵」として機能する。例えば、アプリケーションがユーザーのメール情報をMicrosoft Graph APIから取得したい場合、メールの読み取り権限（「Mail.Read」のような「スコープ」と呼ばれる特定の許可）を持つアクセストークンをMicrosoft Entra IDに要求する。Entra IDからアクセストークンを受け取ったアプリケーションは、そのトークンをHTTPリクエストのヘッダー部分（「Authorization: Bearer <アクセストークン>」という形式）に含めてAPIに送信する。Microsoft Graph APIは、このアクセストークンが有効であるか、そして要求された操作（この場合はメールの読み取り）を実行するのに十分な権限が含まれているかを確認する。これらの条件が満たされて初めて、APIは要求されたデータをアプリケーションに返すのだ。

このような認証・認可の仕組みがどのように連携しているか、全体像を見てみよう。最も基本的なシナリオでは、ユーザーがウェブブラウザを使い、ASP.NET Coreで構築されたウェブアプリケーションにアクセスする。このウェブアプリケーションは、ユーザーの認証が必要な場合、その責任をMicrosoft Entra IDに委ねる。

より複雑なエンタープライズ環境では、次のような登場人物と役割分担がある。まず「User（ユーザー）」がいる。これは、実際にアプリケーションを操作する人間を指す。次に「Browser（ブラウザ）」がある。これはユーザーがウェブアプリケーションにアクセスするためのツールだ。「ASP.NET Core Web Application（ASP.NET Coreウェブアプリケーション）」は、ユーザーが直接対話するアプリケーション本体である。このアプリケーションは、ユーザーのログイン要求を受け取ると、自身で認証を処理せず、Microsoft Entra IDへユーザーを誘導する。そして「Microsoft Entra ID」がある。これがIdentity Providerであり、ユーザーの身元を検証し、認証が成功すればIDトークンとアクセストークンを発行する中核的なサービスだ。最後に「Protected API（保護されたAPI）」が存在する。これは、アプリケーションがユーザーに提供する機能の一部として、特定のデータやサービスを提供するバックエンドのAPI群を指す。このAPIは、通常、アプリケーションからのリクエストに含まれるアクセストークンを検証することで、そのリクエストが正当なものであり、十分な権限を持つユーザーからのものであることを確認してから、応答を返す。

このように、ユーザーはブラウザを通じてASP.NET Coreウェブアプリケーションにアクセスし、ウェブアプリケーションはMicrosoft Entra IDと連携してユーザーを認証する。認証が完了すると、Entra IDはIDトークン（ウェブアプリケーションがユーザーの身元を確認するため）とアクセストークン（ウェブアプリケーションが保護されたAPIにアクセスするため）を発行する。ウェブアプリケーションは、必要に応じてこのアクセストークンを使い、保護されたAPIから必要な情報を安全に取得し、ユーザーに提供する。この一連の流れにより、アプリケーションはユーザーのパスワードを管理する負担から解放され、セキュリティも向上し、様々なサービスと連携しやすい、より堅牢な認証システムが構築されるのだ。