Microsoft Entra IDでSSOログイン用のアプリを登録する手順とつまずきポイント

AzureのMicrosoft Entra ID(旧Azure AD)を使って、WebシステムにSSO(シングルサインオン)でログインできるようにするための、Entra ID側の設定手順をまとめます。

ユーザーの作成からアプリの登録、クライアントシークレットの発行、APIのアクセス許可の設定までを順番に解説し、設定時につまずきやすいポイントもあわせて紹介します。

設定の全体像

Entra ID側で行う作業は次の5つです。

  1. SSOでログインするユーザーを作成する
  2. アプリを登録する
  3. リダイレクトURIを設定する
  4. クライアントシークレットを作成する
  5. APIのアクセス許可を設定する

作業はAzureポータルにログインし、サービス一覧から「Microsoft Entra ID」を開いた画面で進めます。Microsoft Entra 管理センター(entra.microsoft.com)からでも同じ操作ができます。

なお、画面の表記は更新されることがあります。本記事は2026年9月時点の表記で、変更されている箇所は旧表記も併記しています。

1. SSOでログインするユーザーを作成する

左メニューの「ユーザー」をクリックし、「新しいユーザー」→「新しいユーザーの作成」を選びます。

「基本」タブでユーザー プリンシパル名、表示名、パスワードを入力します。パスワードを自動生成にした場合は、ここに表示される初期パスワードを控えておきます。作成したユーザーは、初回ログイン時にパスワードの変更を求められます。

入力が終わったら「確認および作成」→「作成」をクリックします。

「メール」属性を必ず設定する

ユーザー作成時の「プロパティ」タブにある「連絡先情報」の「メール」に、メールアドレスを入力しておきます。

後の手順でアクセス許可に email を追加しますが、ユーザーの「メール」属性が空の場合、IDトークンに email クレームが含まれません。Exchange Onlineのライセンスを割り当てていないユーザーは、この属性が空のままになりがちです。アプリ側でメールアドレスを使ってユーザーを照合する場合、ここを設定していないとログインに失敗します。

作成済みのユーザーは、ユーザーの詳細画面からプロパティを編集して設定できます。

Azureの契約アカウントはSSOの確認に使わない

Azureの契約に個人のMicrosoftアカウント(@outlook.com など)を使っている場合、そのアカウントはテナント内では外部のアカウントとして扱われます。「メール」属性をはじめ、テナント内で作成したユーザーとは扱いが異なるため、SSOのログイン確認には使わず、ここで作成したユーザーを使います。

2. アプリを登録する

左メニューの「アプリの登録」をクリックし、「新規登録」を選びます。

次の項目を入力し、「登録」をクリックします。

  • 名前:任意のアプリ名を入力します。ログイン時の同意画面などでユーザーにも表示されます。
  • サポートされているアカウントの種類:社内のユーザーだけがログインする場合は「シングルテナントのみ」を選びます。旧表記では「この組織ディレクトリのみに含まれるアカウント」です。
  • リダイレクトURI:プラットフォームに「Web」を選び、アプリ側のコールバックURL(例:https://example.com/auth/callback)を入力します。

リダイレクトURIは https で始まる必要があり(localhost を除く)、大文字・小文字も区別されます。アプリ側に設定するURIと1文字でも違うとエラーになるため、コピーして貼り付けるのが確実です。

クライアントIDとテナントIDを控える

登録が完了すると、アプリの「概要」画面に移動します。ここに表示される次の2つは、アプリ側の設定で必ず使うので控えておきます。

  • アプリケーション(クライアント)ID
  • ディレクトリ(テナント)ID

3. リダイレクトURIを設定する

作成したアプリの左メニューから「認証」を開きます。登録時に入力したリダイレクトURIがここに表示されます。

開発環境と本番環境など、リダイレクトURIが複数ある場合はここで追加します。追加したら、画面下部のボタン(「保存」または「構成」)をクリックして確定させます。確定しないまま画面を離れると反映されません。

アプリ側がIDトークンを暗黙的フローで受け取る方式の場合は、「認証」画面の設定で「IDトークン」にチェックを入れます。サーバー側で認可コードを受け取る一般的な構成(クライアントシークレットを使う方式)であれば、チェックは不要です。

4. クライアントシークレットを作成する

左メニューの「証明書とシークレット」を開き、「新しいクライアントシークレット」をクリックします。

説明と有効期限を入力して「追加」をクリックすると、シークレットが作成されます。

「値」は作成直後にしか表示されない

ここが一番の落とし穴です。作成されたシークレットの「値」は、作成直後にしか表示されません。画面を移動すると二度と確認できないので、すぐにコピーして安全な場所に保管します。

また、一覧には「値」と「シークレットID」が並んで表示されますが、アプリ側に設定するのは「値」の方です。「シークレットID」を設定してもログインできません。

値を控え忘れた場合は、新しいシークレットを作成し直します。

有効期限を管理する

有効期限は推奨の180日(6か月)のほか、最長24か月まで選べます。期限が切れるとSSOでログインできなくなるため、期限日を記録しておき、切れる前に新しいシークレットを作成してアプリ側の設定を差し替えます。

シークレットは複数同時に登録できるので、新旧を並行して有効にしておけば、ログインを止めずに切り替えられます。

5. APIのアクセス許可を設定する

左メニューの「APIのアクセス許可」を開きます。アプリの登録時に「Microsoft Graph」の「User.Read」が既定で追加されています。

「Microsoft Graph」をクリックし、「委任されたアクセス許可」の中から次の3つにチェックを入れて、「アクセス許可の更新」をクリックします。

  • openid
  • profile
  • email

「アクセス許可の追加」→「Microsoft Graph」→「委任されたアクセス許可」の順に選んで追加しても同じです。

これらは通常、管理者の同意がなくても使えるアクセス許可です。ただし、テナントのユーザー同意の設定によっては、初回ログイン時に同意画面が表示されたり、ログインがブロックされたりします。確実にするなら「(テナント名)に管理者の同意を与えます」をクリックしておきます。

アプリ側に設定する値

Entra ID側の設定が終わったら、SSOを組み込むアプリ側に次の値を設定します。

  • クライアントID:手順2で控えたアプリケーション(クライアント)IDです。
  • クライアントシークレット:手順4でコピーした「値」です。
  • テナントID:手順2で控えたディレクトリ(テナント)IDです。
  • リダイレクトURI:手順2・3で登録したURIと完全に同じものを指定します。
  • スコープ:openid profile email を指定します。

ライブラリによっては、テナントIDの代わりにIssuer(発行者)やメタデータのURLを求められます。その場合は次の形式で指定します。

https://login.microsoftonline.com/<テナントID>/v2.0

https://login.microsoftonline.com/<
テナントID>/v2.0/.well-known/openid-configuration

これらのURLは、アプリの「概要」画面の「エンドポイント」からも確認できます。

つまずきやすいポイント

  • emailが取得できない:ユーザーの「メール」属性が空になっていないか確認します。
  • AADSTS50011 エラーが出る:リダイレクトURIがアプリ側と完全に一致しているか確認します。末尾のスラッシュや大文字・小文字の違いも対象です。
  • AADSTS7000215 エラーが出る:クライアントシークレットに「シークレットID」ではなく「値」を設定しているか確認します。
  • ある日突然ログインできなくなった:クライアントシークレットの有効期限切れを疑います。
  • Azureの管理アカウントでログインできない:個人のMicrosoftアカウントの場合は、テナント内で作成したユーザーで確認します。

まとめ

Entra ID側の設定は、ユーザー作成 → アプリ登録 → リダイレクトURI → クライアントシークレット → APIのアクセス許可の5ステップです。

画面の操作自体は難しくありませんが、シークレットの「値」の控え忘れと、ユーザーの「メール」属性の未設定は、後から原因に気づきにくいポイントです。設定時に意識しておくと、アプリ側の実装で悩む時間を減らせます。

コメント