アプリの登録とOAuthガイド：安全なアプリ連携のために

By Mirko Peters · 2026-05-04

OAuth 2.0でアプリを登録しましょう。セキュアなアクセスのための認可コードフローを理解します。これはOAuth 2.0認可コード付与の中核となる部分です。

Automatically translated with AI from the original post. Read the English original

認証とアプリ登録を正しく行うことは、単にプロトコルに従うだけではありません。ユーザー、データ、そして組織を安全に保つことそのものです。本ガイドでは、アプリ登録とOAuth 2.0をわかりやすく解説し、Microsoft Entra ID（旧Azure AD）または任意のプロバイダーを使って、標準に基づいたセキュアな認証を構築できるようにします。

本ガイドでは、OAuthの背景にある理由から、Web、モバイル、SaaSアプリで実際に動かすまでの手順と概念を順に説明します。明確な定義、実践的なアドバイス、そして連携を軌道に乗せ、OAuthを初めて扱う開発者がよく陥る落とし穴を避けるためのロードマップも紹介します。初めて検討する方も、高度なエンタープライズ構成を調整している方も、自信を持ってアプリを構築し、アプリに必要な識別子を理解するための適切な場所です。

アプリの登録とOAuthガイド：定義

アプリ登録とは、アイデンティティプロバイダー（Azure AD、Google、Auth0など）にアプリケーションのID を作成して構成し、アプリが認証と認可を安全に要求できるようにするプロセスです。通常、クライアントID、クライアントシークレットまたは証明書の割り当て、リダイレクトURIの定義、アクセス許可やスコープの設定、許可するグラントタイプの構成が含まれます。

アプリの登録とOAuthガイドに関する意外な8つの事実

• クライアントシークレットはログから漏えいする可能性があります：多くの開発者は、デバッグ中に気づかないままクライアントIDやシークレットを記録しています。ログポリシーを厳格にしない限り、アプリ登録の資格情報は脆弱なままです。識別子は常に慎重に扱いましょう。
• リダイレクトURIは想像以上に厳格です：OAuthプロバイダーは、末尾のスラッシュやスキームを含めて完全一致するリダイレクトURIを要求することがよくあります。わずかな違いでも、アプリ登録上は正しく構成されているように見えるフローが動かなくなることがあります。
• パブリッククライアントにはシークレットは不要ですが、保護は必要です：ネイティブアプリやシングルページアプリは、クライアントシークレットを持たないパブリッククライアントとして扱われます。それでも、認可コードの傍受を防ぐためにPKCEと安全なリダイレクト方式を使用する必要があります。
• スコープは既定では最小特権を保証しません：アプリを登録する際、既定のスコープや同意画面が広範なアクセス許可を要求することがあります。最小特権を徹底するには、スコープを明示的に制限し、段階的な同意を取り入れることが不可欠です。
• トークンの取り消しはすべてのプロバイダーで対応しているわけではありません：すべてのIDプロバイダーがトークンの取り消しに対応しているわけではなく、セッション全体で即時にサインアウトさせるとは限りません。そのため、アプリ登録にはセッション管理とリフレッシュトークンのポリシーを含める必要があります。
• アプリ登録のメタデータも攻撃対象領域です：公開されたアプリ名、ロゴ、リダイレクトURIは、慎重に管理されていない場合、攻撃者が巧妙なフィッシングやオープンリダイレクト攻撃を仕掛ける材料になりかねません。
• 自動プロビジョニングによってアクセス許可が誤って構成される可能性があります: アプリ登録を作成するCI/CD自動化では、過度に広範なAPI のアクセス許可が付与されたり、必要なリダイレクト URI が登録されなかったりすることがあります。その結果、エラーが表示されないまま失敗したり、セキュリティ上のリスクが生じたりします。
• 同意の画面設計はセキュリティ判断に影響します：同意ダイアログはわかりにくいため、ユーザーや管理者は広範な同意を与えがちです。アプリ登録とOAuthガイドの中で、明確で必要最小限の同意プロンプトを設計すると、過剰なアクセス許可の付与を減らせます。

OAuth 2.0 と Entra ID の基礎を理解する

OAuth 2.0 は、最新の認証フローの基盤です。アプリはユーザーのパスワードを一切知ることなく、ユーザーのデータやリソースに安全にアクセスできます。ここでは OAuth のプロセスの概要を説明します。OAuth 2.0 の中核は、ユーザー（「リソース所有者」）、アプリ（「クライアント」）、そして ID プロバイダー（「承認サーバー」）が、どのように連携するかを定義することにあります。これにより、ユーザーは自分の情報を引き続きコントロールできます。

では、データへのアクセスを認可するだけでなく、ユーザーを認証したい場合はどうでしょうか。そこで登場するのが OpenID Connect です。OpenID Connect は OAuth 2.0 の上に、安全な ID とサインインの仕組みを重ねます。OpenID Connect を使えば、Microsoft Entra ID や Google などのプロバイダーを通じて、アプリがユーザーを確認するとともに、追加のリソースに対するスコープ付きのアクセス許可を、ひとつの統合された操作で要求できます。

「クライアント ID」「承認エンドポイント」「アクセス トークン」といった用語に出会っても、圧倒される必要はありません。これらはすべて、「誰が誰と通信し、何を行えるのか」を定義するという考え方につながります。特に Microsoft Entra ID は、これらのプロトコルを使って、シングルテナントの業務アプリから大規模なマルチテナントの SaaS 製品まで対応できる、標準ベースの基盤を開発者に提供しています。

これらの基礎を理解していれば、確立された土台の上に構築できます。シナリオに合った OAuth フローを選ぶことが重要です。たとえば、Web アプリには認可コード フロー、スマート TV にはデバイス フローを選択します。そうすることで、ユーザーが信頼でき、コンプライアンス チームも評価する、安全でシンプルな サインインを実現できます。

アプリの登録と OAuth ガイド: Microsoft Entra ID での OAuth 2.0 でよくある間違い

このアプリの登録と OAuth ガイドでは、チームが Microsoft Entra ID（Azure AD）で OAuth 2.0 を実装する際によく犯す間違いと、それがセキュリティ、機能、ユーザー エクスペリエンスにどう影響するかを解説します。

• OAuth 2.0 と OpenID Connect の概念を混同すること（例: アクセス トークンしか発行されない場面で ID トークンを期待する）。
• OAuth フローを誤って使用すること。最新のアプリに対して、PKCE 付きの認可コード フローではなく、暗黙的フローが適切だと考えてしまうケースです。

• リダイレクト URI の登録が誤っていること（スキームの誤り、末尾のスラッシュ、本番環境での localhost の使用など）。
• 機密クライアント アプリにパブリック クライアントの設定を使用する、またはその逆を行うこと。トークン エラーの原因になったり、シークレットが漏えいしたりします。
• API のアクセス許可やスコープを正しく設定していないこと、または必要な場合に 管理者の同意を付与し忘れること。

• クライアント シークレットをクライアント側のコードや公開リポジトリに埋め込むこと。
• クライアント シークレットや証明書を定期的にローテーションしないこと、またはアプリの登録から期限切れの資格情報を削除しないこと。
• 短期間有効な証明書やマネージド ID を使えるにもかかわらず、不必要に長期間有効なシークレットを使用すること。

• トークンを適切に検証しないこと（発行者、対象ユーザー、署名、nonce、有効期限の確認漏れ）。
• アクセス トークンや更新トークンを安全でない方法で保存すること（保護なしでブラウザーのローカル ストレージに保存するなど）。
• Entra ID から返されたスコープやロールを検証せずに、トークンの内容を信頼すること。

• ユーザーの同意があればアプリの権限が十分だと考えること。一部のアクセス許可には管理者の同意が必要であることに気づいていないケースです。
• 過剰なアクセス許可やスコープを要求すること。これは不要なリスクを生むだけでなく、同意時の拒否率も高めます。

• Entra ID の更新トークンのローテーションや取り消しのポリシーに対応しないこと。その結果、予期しないサインアウトが発生します。
• パブリック クライアントで更新トークンを使用する際に、適切な保護を施さないこと（PKCE と適切なトークンの有効期間を使用してください）。

• テナントをまたいで動作させるアプリのマルチテナント設定を、適切に構成していないこと。
• 適切でないエンドポイント（テナント固有と共通のどちらか）を使用し、サインインや同意に関する問題が発生すること。

• 条件付きアクセス、MFA、またはデバイスのコンプライアンス ポリシーが適用された状態で、アプリの動作を検証していないこと。
• トークンが常に同じ条件で発行されると想定するのは危険です。ポリシーによってはトークンの発行がブロックされたり、追加の認証手順が求められたりします。

• Microsoft identity platform (v2) の推奨事項ではなく、従来の OAuth フローや Azure AD v1 のパターンに従ってしまうこと。
• コミュニティのサンプルを、安全な実装（PKCE、安全なストレージ、適切な検証）になっているか確認せずに使用すること。

• 認証の失敗やトークン発行時のエラーをログに記録しないと、原因の特定が困難になります。
• 生のエラーメッセージをそのままユーザーに表示せず、実際に対処できるガイダンスに変換してください。

このアプリの登録と OAuth のガイドを使って実装を見直し、Microsoft identity platform のベストプラクティスに従ってください。Entra ID で OAuth 2.0 を統合する際のセキュリティおよび運用上のリスクを減らせます。

OAuth 設定のためのアプリ登録の前提条件

登録画面を開いてアプリ名をポータルに入力する前に、いくつか必須事項を確認しておきましょう。まず、組織の Microsoft Entra 管理センター、または利用中の ID プロバイダーの管理コンソールにアクセスできる必要があります。近道はありません。適切なアクセス許可がなければ、画面に入る前に行き詰まってしまいます。

次に、構築するアプリケーションの種類と、その機能に必要な識別子を決めます。Web アプリでしょうか、シングルページ アプリケーションでしょうか、モバイル アプリでしょうか、それとも自動化されたサービスでしょうか。種類ごとに認証と承認の要件が異なります。ここを先に決めておくと、後で選ぶセキュリティ設定が定まります。

また、アプリを利用するユーザーの範囲を整理することも重要です。自社の組織内のユーザーだけが対象でしょうか（シングルテナント）。それとも他社や一般ユーザーにもサービスを提供する必要があるでしょうか（マルチテナント）。この違いによって、登録時の設定、適用されるユーザー ディレクトリ、ユーザーに表示される同意のフローが変わります。

最後に、サインイン後のリダイレクトに許可する URL、サポートするプラットフォーム（iOS、Android、Windows など）、アプリが要求するアクセス許可（「スコープ」）といった技術的な詳細を確認します。これらを事前に揃えておくと、セットアップの時間を大幅に節約でき、後から無効な URI やアカウントの種類の不一致といったよくある問題を避けられます。

Microsoft Entra ID へのアプリの登録方法

Microsoft Entra ID（旧 Azure AD）にアプリを登録することは、認証と API アクセスのすべての基盤になります。手順は Entra 管理センターから始まります。そこで新しいアプリケーション登録を作成し、組織のディレクトリ内でアプリに固有の ID（「クライアント ID」と呼ばれます）を割り当てます。

アプリケーションの名前を入力し、誰がそのアプリを使用できるかを選択します。組織内のみ、複数の組織、または任意の Microsoft アカウントから選べます。この手順は、特に SaaS アプリや B2B アプリでは非常に重要です。アプリの利用範囲と、テナントの同意の管理方法が決まるためです。

対象の選択後は、アプリのプラットフォームの詳細を設定します。Web アプリではリダイレクト URI を追加します。モバイル アプリやシングルページ アプリでは、プラットフォーム固有の設定により、スムーズなサインイン体験を実現します。Entra ポータルでは、アプリが自身の ID を証明するために使用するクライアント シークレットや証明書などの資格情報を追加する手順が案内されます。

登録を完了すると、アプリは OAuth 2.0 の標準に準拠し、認証フローが安全かつコンプライアンスに適合した状態を保てます。シングルテナントで運用する場合でも、マルチテナントを目指す場合でも、これらの設定を早い段階で理解しておくことが、将来の拡張と統合に向けた確かな土台になります。

Microsoft Entra ID にアプリを登録する主なメリット

• 一元的な ID 管理: 単一の Entra ID テナントから、アプリの認証、承認、およびユーザー IDをまとめて管理できます。
• 安全な OAuth フロー: 組み込みの OAuth 2.0 と OpenID Connect のサポートを活用して、安全なサインイン、トークン発行、委任されたアクセスを実装できます。
• シングル サインオン (SSO): Microsoft 365、Azure、その他の連携サービス全体でシームレスな SSO を提供し、ユーザー体験を向上させるとともに、パスワードの入力を減らせます。
• きめ細かなアクセス許可の制御: 委任されたアクセス許可とアプリケーションのアクセス許可の両方について、きめ細かなAPIアクセス許可を定義および管理し、同意の体験と最小権限のアクセスを実現します。
• 条件付きアクセスとセキュリティ ポリシー: 多要素認証、デバイスのコンプライアンス、場所、リスクベースのポリシーを適用し、アプリへのアクセスと機密データを保護します。
• 管理されたアプリのシークレットと資格情報: クライアント シークレット、証明書、マルチテナント構成を安全に保存してローテーションし、ライフサイクル管理の手法によってアプリの使用の整合性を維持します。
• Microsoft プラットフォーム サービスとの統合: 標準化されたトークンと同意モデルを使用して、Microsoft Graph、Azure API、Teams、その他のプラットフォーム機能にアクセスします。
• ハイブリッドおよびマルチプラットフォーム アプリのサポート: Web、モバイル、デスクトップ、サービス間のシナリオにわたってユーザーを認証します。一貫した ID プロトコルを使用し、各アプリが適切な識別子を使用するようにします。
• 監視と監査: ログ、サインイン レポート、セキュリティ分析情報を活用して異常を検出し、インシデントを調査し、コンプライアンスを維持します。
• スケーラビリティとエンタープライズへの対応力: Entra ID のグローバル インフラストラクチャ、マルチテナント オプション、エンタープライズ機能を活用し、拡大するユーザー ベースや複雑な組織要件をサポートします。
• 開発者ツールとドキュメント: SDK、サンプル コード、およびアプリの登録と OAuth のガイドを活用して、実装を加速し、よくあるシナリオのトラブルシューティングを行います。

Entra ID アプリのリダイレクト URI とプラットフォーム設定の構成

アプリの登録時に正しいリダイレクト URI を設定するのは簡単に見えますが、このステップはセキュリティを左右する重要な作業です。リダイレクト URI は、ログインに成功した後に、ユーザーをトークンとともにどこへ送るかを Entra ID に伝えます。設定時には Entra によって厳格なルールが適用されます。ワイルドカード ドメインは使用できず、危険な URI スキームも使用できず、攻撃者に悪用される余地も残しません。

シングル ページ アプリケーション (SPA) を構築する場合、通常はアプリのドメインを指す HTTPS URL を使用し、データを取得する際の通信を安全に保ちます。ネイティブ アプリでは、アプリのバンドルまたはパッケージ名に紐づいた URI スキームが必要です。これにより、同じデバイス上の無関係なアプリがトークンを乗っ取ることを防げます。Web アプリは通常、ログイン コールバック エンドポイントを使用します。各エンドポイントは明示的に登録する必要があります。

ここで設定を誤ると、典型的な「リダイレクト URI の不一致」エラーが発生するだけでなく、さらに深刻な問題として、攻撃者がトークンを傍受する扉を開いてしまいます。アプリが実行されるすべてのプラットフォームと、それに対応するリダイレクト URI を事前に洗い出しておくことで、認証をスムーズに進め、安心して運用できます。

クライアント URL を変更したとき、プラットフォームを追加したとき、またはテストや本番などの環境を拡張したときは、必ずアプリの登録を更新してください。これらの URI を厳格かつ整理された状態に保つことが、トークンのフローを確実に守るための第一歩です。

OAuth フローとトークン管理の基本

OAuth 2.0 は、Web ログイン、モバイル サインイン、サーバー間の呼び出し、ユーザーが不在のままアプリが動作する場合など、さまざまなユースケースに対応する認可フローの集合を中心に構成されています。これらの中で最も一般的かつ安全なのが認可コード フローです。機密性の高いトークンをブラウザーやモバイル アプリの外に置かないよう設計されており、セキュリティを最優先にしています。

ユーザーの認証と同意が完了すると、アプリは有効期間の短いコードを受け取ります。アプリはこのコードをトークン エンドポイントで交換し、アクセス トークンと更新トークンを取得する必要があります。これらのトークンはデータへの期間限定のアクセスを付与します。期限が切れた場合は、更新トークンを使って新しいアクセス トークンを要求し、セッションを維持できます。

トークン管理は有効期限を扱うだけではありません。あらゆる場面でトークンを安全に保つことが重要です。これには、安全な通信 (HTTPS など) の使用、クライアント側のコードにシークレットを決して露出させないこと、スコープを要求する際に最小権限の原則を適用することが含まれます。

このセクションでは、ユーザー、アプリ、プラットフォーム間で OAuth が行う重要なハンドシェイクの仕組みを理解するための土台を整えます。堅牢なトークン管理が、エンドユーザーと自動化されたシステムの双方にとって、持続的かつ安全なワークフローをどのように支えるのかも確認します。

OAuth 認可コード フローの実装

1. 認可の開始: アプリは、クライアント ID、要求するスコープ、CSRF 対策のための一意でランダムな state パラメーターなどの情報を含めて、ユーザーを Entra ID の認可エンドポイントへリダイレクトします。
2. ユーザーによるアクセス許可の付与: ユーザーは同意画面を確認します。この画面には、アプリが必要とするアクセス許可が明示されており、ユーザーはアクセスを承認します。
3. 認可コードを受け取る: 同意の後、Entra ID は指定されたリダイレクト URI にユーザーをリダイレクトし、一時的な認可コードと、最初に設定した state の値を渡します。
4. コードをトークンに交換する: バックエンドが、コードをクライアント資格情報(PKCE を使用している場合は code verifier も)とともに Entra のトークン エンドポイントへ安全に送信します。検証に成功すると、アクセス トークン(多くの場合はリフレッシュ トークンも)が返されます。
5. トークンを使って API にアクセスする: アプリは各 API 要求にアクセス トークンを付与し、ユーザーに代わって認可されていることを証明します。アクセス トークンの有効期間は短く、漏えいしたときの影響を抑えます。リフレッシュ トークンは、継続的なセッションのために新しいアクセス トークンを取得する際に使われます。

この手順を正しい順序で確実に実装することで、セキュリティの穴をふさぎ、認可コードの横取りやトークンの不正利用などの攻撃を防ぎやすくなります。特にパブリック クライアントを扱う場合や機密性の高いデータを取り扱う場合に重要です。

アクセス トークンとリフレッシュ トークンの有効期限を管理するためのベスト プラクティス

1. トークンを安全に保存する: iOS の Keychain や Android の Keystore など、OS が提供する安全なストレージを使用するか、サーバー側では暗号化されたシークレット マネージャーを利用してください。トークンをアプリのバイナリにハードコードしたり、ログに出力したりしてはいけません。
2. トークンの有効期間を尊重する: 各トークンの有効期限(exp クレーム)を監視し、期限切れの前に先回りしてリフレッシュしてください。これにより、API 要求の失敗やユーザー体験の低下を防げます。
3. トークンのローテーションに対応する: 常に最新のリフレッシュ トークンを使用し、再利用された古いトークンはすぐに破棄してください。これにより、トークンが侵害された場合の影響を抑えられます。
4. トークンごとにアクセス許可を最小限にする: 必要なスコープだけを要求し、有効期間の短いアクセス トークンを優先してください。トークンが漏えいしたり盗まれたりした場合の被害を大幅に減らせます。

さまざまな状況における OAuth 実装の保護

OAuth 連携を正しく実装するには、手順を順番にこなすだけでは不十分です。アプリのアーキテクチャや利用パターンに合わせて、多層的なセキュリティを組み込むことが重要です。ブラウザで動作するアプリでも、スマートフォンのアプリでも、クラウド上だけで動作するアプリでも、それぞれの状況に合った認証戦略が必要です。

PKCE(Proof Key for Code Exchange)のような仕組みは、パブリック クライアントのコード フローを保護し、攻撃者が認可コードを横取りしてトークンに交換することを防ぎます。一方、安全な環境で動作するアプリでは、ID の証明と信頼の管理には、クライアント シークレットと証明書が最も有効な手段になります。

トークンを慎重に保存し、権限レベルに十分注意することで、意図しない漏えいを防ぎ、万一問題が起きた場合の影響範囲を抑えられます。PKCE、シークレット、証明書、適切なスコープ設定といったセキュリティ手段を適切に選ぶことで、攻撃対象領域を大幅に減らし、安定して準拠した運用を行える可能性が高まります。

以下では、一般的な脅威への対策として実績のある戦略を紹介します。あらゆる種類のアプリや環境に合わせて OAuth の設定を調整し、堅牢な保護を実現するための内容です。

PKCE がパブリック クライアントの OAuth 認可を保護する仕組み

PKCE(Proof Key for Code Exchange)は、シークレットを安全に保存できないモバイル アプリやブラウザー ベースのアプリといったパブリック クライアントで OAuth を使用する際に不可欠です。認可コード フローを開始すると、アプリはランダムな「code verifier」と、そのハッシュ値である「code challenge」を生成します。これらの値は、ユーザーの操作と最終的なトークン要求に伴って送信されます。攻撃者が認可コードを取得しても、この秘密の verifier がなければトークンに交換できないため、Microsoft Entra ID などのプラットフォームではコード横取り攻撃がほぼ不可能になります。

クライアント シークレット、証明書、フェデレーション資格情報の管理

• クライアント シークレット: 信頼されたバックエンド サービスなどの機密クライアントが、トークン エンドポイントで自身の ID を証明するために使用します。シークレットは安全な保管場所に保存し、定期的にローテーションし、クライアント側のアプリ コードに含めることは絶対に避けてください。
• 証明書: より高い保証レベルが必要な場合は、プレーンなシークレットではなく X.509 証明書を使用し、アプリケーション識別子のセキュリティを高めてください。証明書は公開鍵と秘密鍵のペアによって、より安全な検証を可能にします。規制の厳しい業界や、厳格なコンプライアンス要件があるアプリに最適です。
• フェデレーション資格情報: 「独自の ID を持ち込む」構成では、Microsoft Entra のフェデレーション ID や外部プロバイダーなどのフェデレーション資格情報を使用します。これにより、シークレットを直接扱わずに認証でき、管理の負担を減らせます。
• パイプラインでの取り扱い: CI/CD ワークフローでは、必要に応じてシークレットや証明書を注入し、ローテーションしてください。ソース管理にハードコードすることは決してしないでください。自動化された有効期限アラートを設定すると、さらに耐障害性が高まります。

トークンの保護と特権の露出の低減

• トークンは、OSの資格情報ボールトや暗号化されたサーバー環境など安全な場所にのみ保存し、ユーザーがアクセスできるストレージには保存しないでください。
• トークンは必ずHTTPSなどの安全な経路で送信してください。平文のHTTPではトークンが傍受されるおそれがあります。
• 各トークンには必要最小限のアクセス許可(「スコープ」)だけを要求してください。アプリに必要な範囲を超えて要求してはいけません。
• トークンの使用状況と特権の割り当てを定期的に監査し、気付かないうちにアクセス許可が広がっていく状態を防いでください。

モバイルアプリおよびネイティブアプリにおけるOAuthのベストプラクティス

現在のモバイルアプリやネイティブアプリには特有の課題があります。デバイスの紛失、アプリ間のストレージ共有、そしてユーザーが素早く、ほぼ意識させないサインインを期待することなどです。そのため、iOS、Android、デスクトップのそれぞれで、組み込みのSDKと実績のあるストレージの仕組みを使ってOAuthのベストプラクティスに従うことが、大きな違いを生みます。

Microsoft Entra ID向けのMSALのような適切なSDKを使えば、トークンの管理、更新処理、OSレベルの安全なストレージとの連携といった負担の大きい作業の多くを任せられます。機密性の高いトークンについては、これらのSDKがデフォルトで最も安全な保存先を選択し、デバイスやOS固有の細かな違いにも対応します。

シームレスなユーザー体験にも目を向けてください。ユニバーサルリンク、ディープリンク、システムブラウザーのフローを使えば、ユーザーは迷うことなくサインインを完了でき、フィッシングのリスクも減らせます。適切に構成されていれば、アプリはユーザーを安全で信頼できるシステムのWebビューに誘導し、サインイン完了後に再びアプリ内へ安全に戻します。ポップアップは表示されず、トークンが漏えいすることもありません。

これらのベストプラクティスは、トークンを安全に保つだけでなく、エンドユーザーの信頼を築くことを目的としています。その結果、アプリの採用率が高まり、将来のサポート対応の負担も軽減されます。

ユニバーサルリンクとファーストパーティのネイティブ認証

iOSのユニバーサルリンクとAndroidのアプリスキームを使うと、ユーザー認証をはるかに安全にできます。アプリのIDに紐付いた、OSが検証済みのリンクを使うことで、不正なアプリがサインインのリダイレクトを横取りし、本来のものではないトークンを取得することを防げます。ネイティブ認証では信頼できるシステムブラウザーを利用するため、実際のユーザー本人がサインインします。これにより、フィッシング、トークンの盗み見、無関係なアプリへの誤ったログインを防止できます。これらを組み合わせることで、一般的なモバイルのOAuth脅威にほぼ対抗できる、シームレスで安全な体験をユーザーに提供できます。

OAuthエラーと高度なシナリオのトラブルシューティング

OAuthの統合が初回で完璧に動作することはほとんどありません。エラーや想定外のエッジケースは、いわば避けて通れないものです。多くの場合、リダイレクトURIの不一致、有効期限切れのコード、誤ったクライアントシークレットが原因で、認証フローが停止し、アプリケーションの利用に影響します。このセクションでは、エラー応答の読み解き方、失敗したトークン交換の追跡方法、そしてヘルプデスクに問い合わせが来る前に問題を切り分ける方法を解説します。

基本を超えると、サーバー間のアプリ通信、IoTデバイスのサインイン、より強固なプロトコル保証が必要な場合など、専用のOAuth拡張機能や非対話型フローが求められるシナリオがあります。サービスアカウント、相互TLS、デバイスコードフローは、こうした要件に対応するために設計されています。

よくある失敗と高度なユースケースの両方を理解しておけば、アプリのエコシステムが複雑になっても、堅牢なOAuthソリューションのトラブルシューティング、設計、保守を適切に行えるようになります。

トークンエンドポイントで厄介なエラーに直面している場合でも、入力デバイスが限られていたりヘッドレスのサービスが至る所に存在したりする実際の環境に備える場合でも、これらの知見によって統合を円滑かつ安全に保てるはずです。

OAuthエラー応答とコード交換の失敗の読み解き方

• 無効なリダイレクトURI: 登録済みの一覧とリダイレクトが一致しない場合に発生します。入力値と大文字・小文字を再確認してください。
• 有効期限切れの認可コード: ユーザーの操作が遅すぎる場合や、コードが再利用された場合に発生します。認可コードは必ず一度だけ使用し、受け取ってからすぐに使ってください。
• クライアント資格情報の不一致: 誤ったシークレットまたは証明書が提供されています。資格情報を確認し、必要に応じてローテーションしてください。
• 無効なスコープまたはリソース: 要求したAPIまたはスコープが許可されていない、もしくはタイプミスがあります。構成とアプリのアクセス許可を確認してください。

サービスアカウント、入力が制限されたデバイス、OAuth拡張機能

• サービスアカウント(クライアント資格情報フロー): ユーザーを介さずにアプリが認証できる仕組みです。自動化やサーバー間のジョブに適しています。
• デバイスコードフロー: スマートTVやIoTデバイス向けの仕組みで、別のデバイス上でユーザーに操作を促します。ブラウザーを利用できない環境に適しています。
• 相互TLS拡張機能: サーバーとクライアントの両方で証明書を使用します。機密性の高い統合の安全性を高め、アプリが強力な認証方式を使用していることを保証します。
• 動的クライアント登録: 大規模な SaaS やマルチテナント システムでアプリのオンボーディングを自動化し、大規模な資格情報の管理を簡素化します。

Entra ID でのアプリの登録と OAuth ガイド

長所

• 一元化された ID 管理: Microsoft Entra ID と統合され、サービス全体でユーザーとアプリの ID を一貫して管理できます。
• 強力なセキュリティ制御: OAuth 2.0、OpenID Connect、条件付きアクセス、きめ細かなアクセス許可(スコープとロール)をサポートします。
• 業界標準のプロトコル: 広くサポートされた OAuth/OIDC 標準を活用し、サードパーティのツールやライブラリとの相互運用を容易にします。
• 詳細なアプリ構成: リダイレクト URI、証明書とシークレット、API のアクセス許可、アプリのブランディングオプションを構成できます。
• きめ細かな同意モデル: 委任されたアクセス許可とアプリケーションのアクセス許可をサポートし、管理者の同意フローによって過剰な権限を持つアプリを制限します。
• エンタープライズ向け機能: マルチテナント アプリ、B2B コラボレーション、Microsoft 365 および Azure サービスとの統合をサポートします。
• 監視と監査: アプリの登録と OAuth フローに関する組み込みのログ、サインイン履歴、監査証跡を提供し、コンプライアンスとトラブルシューティングに役立ちます。
• 開発者向けツールと SDK: 豊富な Microsoft ID プラットフォーム SDK、ドキュメント、クイックスタート サンプルにより、実装を効率化できます。

短所

• 初心者には複雑: 構成とアクセス許可のモデル(リダイレクト URI、応答 URL、暗黙的フローと認可コード フロー、スコープなど)は、新しい開発者にとってわかりにくい場合があります。
• セキュリティ機能の学習コストが高い: 条件付きアクセス、マネージド ID、高度なトークン設定を安全に構成するには、より深いセキュリティの知識が必要です。
• アクセス許可が肥大化するリスク: 不適切な同意や広範なアプリのアクセス許可は、定期的に見直さないと、過剰な権限を持つアプリケーションにつながる可能性があります。
• トークン管理の注意点: 更新トークン、トークンの有効期間、トークンの取り消しの扱いはプラットフォームごとに動作が異なり、統合時の問題を引き起こすことがあります。
• テナント境界に関する考慮事項: マルチテナント アプリの動作と管理者の同意プロンプトは、テナントをまたぐシナリオで運用の複雑さを増します。
• UI と用語の変更: Microsoft は Entra の UI と名称(Azure AD → Entra ID)を定期的に更新するため、ドキュメントとの食い違いや混乱が生じることがあります。
• Microsoft エコシステムへの依存: Entra ID の機能に密接に結び付くため、Microsoft 以外の ID プロバイダーへの移行は、再構築なしには難しい場合があります。
• 設定ミスの可能性: アプリ登録の設定(リダイレクト URI、応答 URL、暗黙的フローの設定など)を誤ると、セキュリティ上の脆弱性が生じたり、認証フローが動作しなくなったりする可能性があります。

OAuth を成功させるための次のステップと主要なコミュニティ リソース

OAuth の設定が完了し、順調に動いているようですが、まだ気を抜かないでください。トークンを取得するアプリケーションが正しく構成されていることを確認してください。基本的な配線は最初の一歩にすぎません。アプリを際立たせ、ユーザーを守りたいのであれば、今こそ追加の機能に目を向けるときです。高度なクライアント ライブラリを調べ、Microsoft Graph を試し、統合をより強固に、そして関係者全員にとってより円滑にできる新しい ID 機能を探ってみてください。

また、これをひとりで解決する必要はありません。Microsoft Entra ID のドキュメントは非常に充実しており、最新のガイド、コード サンプル、そして手元に置いておきたくなるような技術仕様がそろっています。特に OAuth とクラウド ID の標準は変化し続けるため、更新情報を定期的に確認する習慣をつけてください。

アプリの登録はうまくいきましたか。それは良かったです。次は、現場の人たちがどのように工夫しているかを見てみましょう。開発者フォーラム、公式のディスカッション ボード、さらに認証ライブラリの GitHub リポジトリものぞいてみてください。壁にぶつかったときは、同じ問題をすでに解決した人がいるか、少なくとも十分に不満の声を上げていて、誰かが答えてくれているものです。

試行錯誤しながら学ぶタイプの方は、無料試用版、テスト テナント、パブリック プレビュー機能を確認してみてください。これらを使えば、(安全な環境で)いろいろ試して、実際のユーザーに変更を展開する前に何が有効かを確認できます。また、OAuth とセキュリティはコミュニティ全体で取り組むものですので、成功事例や疑問点を共有してください。それがエコシステム全体の健全性と成長につながり、OAuth の仕組みを皆が理解する助けにもなります。

アプリの登録と OAuth ガイド チェックリスト - Entra ID

• アプリケーションの種類とアクセス モデルを計画します。シングルテナント、マルチテナント、個人用 Microsoft アカウントのいずれにするかを決め、SPA、Web アプリ、モバイル、デーモン、サービス アプリのどれにするかを判断します。
• Entra ID でアプリケーションを登録する — わかりやすい名前とサポート対象のアカウントの種類を指定して、新しいアプリの登録を作成します。
• リダイレクト URI を構成する — 各プラットフォームに適したリダイレクト/コールバック URI を追加します（https、カスタム スキーム、開発用の localhost など）。
• アプリケーション プラットフォームの設定を行う — SPA、Web、モバイル & デスクトップのプラットフォーム オプションを有効にし、必要に応じて暗黙的フローや付与フローを構成します。
• クライアント シークレットの作成と管理 — 機密クライアント用のクライアント シークレットを生成し、有効期限を確認したうえで、Key Vault などに安全に保管します。
• 認証に証明書を使用する — 長期間有効なシークレットの代わりに、運用環境の機密クライアントには公開キー証明書をアップロードします。
• API のアクセス許可を構成する — アプリに必要な Microsoft Graph またはカスタム API のスコープとアクセス許可を追加します。
• 必要に応じて管理者の同意を付与する — テナント全体の同意が必要な委任されたアクセス許可について、管理者の同意を要求して記録します。
• カスタム スコープを定義して公開する（API の場合） — 「API の公開」でスコープを追加し、スコープ名、説明、管理者の同意の表示名を定義します。
• アプリ ロールを設定する（必要な場合） — ロールベースのアクセス制御のために、アプリケーション ロールと委任ロールを定義し、ユーザー、グループ、またはクライアント アプリに割り当てます。
• SPA から API を呼び出す場合の CORS を構成する — API で許可するオリジンを追加するか、ゲートウェイや CORS ポリシーを構成します。
• OAuth 2.0 フローを選択する — 状況に応じて、認可コード フロー（パブリック クライアントでは PKCE と併用）、デーモン アプリ向けのクライアント資格情報フロー、またはデバイス コード フローを選択します。
• パブリック クライアント向けに PKCE を実装する — SPA やネイティブ アプリでは Proof Key for Code Exchange を必須にし、認可コードの傍受を防ぎます。
• トークンを正しく検証する — Microsoft の ID ライブラリまたは JWT 検証ロジックを使用して、発行者、対象者、署名、有効期限、必要な要求を検証します。
• Microsoft 認証ライブラリ (MSAL) を使用する — トークンの取得、キャッシュ、更新、各プラットフォームでの安全な取り扱いには、MSAL の利用を優先します。
• 条件付きアクセスと MFA を構成する（必要な場合） — アプリの登録またはユーザーのサインイン フローにポリシーを適用し、セキュリティ制御を徹底します。
• サインインと監査ログを監視する — ログ記録を有効にし、Entra ID のログでサインイン イベント、同意、管理操作を確認します。
• 最小特権のアクセス許可を実装する — 必要なアクセス許可のみを要求し、公開範囲を最小限に抑えるために段階的な同意を優先します。
• シークレットと証明書を定期的にローテーションする — 自動ローテーションと、有効期限が近づいた資格情報に対するアラートを実装します。
• クライアント側のコードとストレージを保護する — クライアント アプリにシークレットを保存しないようにし、安全なストレージとプラットフォームのベスト プラクティスを適用します。
• 開発/ステージング環境でサインインとトークンのフローをテストする — 認証フロー、トークンの有効期間、更新ロジック、エラー処理、同意の UX を検証します。
• ユーザーと管理者向けのドキュメントを準備する — 同意の手順、必要なアクセス許可、トラブルシューティングのガイダンスを含めます。
• アプリの登録を定期的に見直して更新する — 古い、または使用されていないアプリがないか、アクセス許可、ロール、シークレット、登録内容を監査します。
• ネットワークと API の保護を適用する — バックエンド API を保護するために、API Management、WAF、レート制限、サービス エンドポイントの利用を検討します。

Azure アクセス トークン 利用 OAuth 認証

アプリ登録と OAuth ガイドとは何か、またなぜ重要なのか？

アプリ登録と OAuth ガイドでは、（たとえば Azure を使用して）ID プロバイダーにクライアント アプリケーションを登録し、OAuth 2.0 認可フローを実装して、保護されたリソースへのアクセスを安全に要求できるようにする方法を説明します。Web アプリケーション、シングルページ アプリ、デスクトップ アプリ、Web サーバー バックエンドのいずれを開発する場合でも重要です。アプリケーションは、アクセス トークンを取得し、必要に応じて ID トークンを受け取るために、アプリ ID（アプリケーション ID）とクライアント ID、そして（機密クライアントの場合は）クライアント シークレットを必要とするためです。

Azure アプリを登録して、アプリケーション ID とアプリ ID を取得するにはどうすればよいですか？

Azure アプリを登録するには、Azure ポータルで新しいアプリの登録を作成し、名前とリダイレクト URI を指定します。その後、アプリケーションの概要に表示されるクライアント ID（アプリケーション ID）を控えておきます。アプリが機密クライアント（Web サーバーや従来型の Web）の場合は、クライアント ID とともに使用するクライアント シークレットを作成します。この登録済みアプリは、認可に使用され、Microsoft のサービスからアクセス トークンを要求するために使われます。

シングルページ アプリにはどの OAuth 2.0 認可フローを使用すべきですか？

シングルページアプリケーションでは、暗黙的フローではなく、PKCE（Proof Key for Code Exchange）付きの認可コード フローを使用してください。これにより、アプリケーションがトークンを安全に取得できます。PKCE 付きのコード フローでは、ブラウザーで動作するクライアントからでも安全にコードをアクセス トークンと交換できます。そのため、クライアント シークレットをブラウザーに露出させることなく、シングルページアプリで OAuth を利用できます。

認可要求はどのように機能し、どのパラメーターが必要ですか？

認可要求は、ID プロバイダーの認可エンドポイントに送信され、通常は client_id（アプリ ID）、response_type（例: code）、redirect_uri、scope、state を含みます。PKCE 付きの認可コード フローを使用するシングルページアプリでは、code_challenge と code_challenge_method も含めます。ユーザーが認証して同意（OAuth の同意）を行うと、認可サーバーは redirect URI にコードを返します。アプリケーションは、このコードをアクセス トークンと交換できます。

アクセス トークンの交換（コードからアクセス トークンへ）はどのように実装すればよいですか？

認可コードを受け取ったら、クライアント アプリケーションは、code、client_id（機密クライアントの場合は client_secret も）、redirect_uri、grant_type=authorization_code を含めてトークン エンドポイントに要求を POST します。PKCE を使用する場合は、code_verifier も含めます。トークン エンドポイントは、アクセス トークン、要求された場合は ID トークン、そしてアクセス トークンの期限切れ時に新しいアクセス トークンを取得するための更新トークンを返す場合があります。

アクセス トークンを取得し、API の呼び出しに使用するにはどうすればよいですか？

選択した OAuth 2.0 認可フローを完了し、トークン エンドポイントを呼び出してアクセス トークンを取得します。アクセス トークンを取得したら、Microsoft のサービスやその他の API（例: Google カレンダーやカスタム API）を呼び出す際に、Authorization ヘッダーに Bearer として設定して送信します。アプリケーションからの要求が承認されていることを確認するため、Web サーバーまたはリソース側でトークンを検証してください。

アクセス トークンが期限切れになった場合はどうすればよいですか？また、新しい更新トークンはどのように取得しますか？

アクセス トークンが期限切れになったら、更新トークンがあれば、grant_type=refresh_token を指定してトークン エンドポイントに新しいアクセス トークンを要求します。フローやプロバイダーによっては、更新時に新しい更新トークンが発行される場合もあれば、同じ更新トークンが再利用される場合もあります。更新トークンがない場合（パブリック クライアントや短期間のフローなど）は、ユーザーをアプリにリダイレクトして、新たに認可要求を行ってください。

Web アプリケーションとモバイル アプリまたはデスクトップ アプリで、アプリの登録を分ける必要がありますか？

従来の Web サーバー、シングルページアプリ、デスクトップ アプリなど、アプリケーションの種類が大きく異なる場合は、通常、アプリの登録を分ける必要があります。リダイレクト URI、クライアント シークレット、許可されるフローがアプリの種類によって異なるためです。アプリの登録を分けることで、アプリの種類ごとに特定の認可フローとリダイレクト URI を構成できます。

クライアント アプリの登録と、テナント内のアプリケーションの違いは何ですか？

クライアント アプリの登録とは、ID プロバイダー内の特定の登録エントリ（Azure アプリ）を指し、リダイレクト URI やシークレットなどの構成を保持します。テナント内のアプリケーションとは、その登録が特定の Microsoft Entra テナント内に存在し、そのテナント内でロールやアクセス許可を割り当てられることを示します。アプリの登録は、要件に応じてマルチテナントにもシングルテナントにもできます。

Microsoft のサービスにアクセスするにはどうすればよいですか？また、必要なアクセス許可は何ですか？

認可要求でアプリケーションに必要なスコープを指定して、アクセスを要求します。Microsoft のサービスの場合は、Azure アプリの登録で API のアクセス許可を構成し、ユーザーに同意（OAuth の同意）を求めるか、管理者がテナント全体の同意を付与します。アプリケーションは、アプリケーション要求の下で User.Read やカスタム API のスコープなどを要求し、そのアクセス トークンを使用してサービスを呼び出します。

クライアント シークレットを保護し、シングルページアプリで資格情報が漏えいしないようにするにはどうすればよいですか？

シングルページアプリはクライアント シークレットを保存すべきではありません。ブラウザーで実行されるコードは検査できてしまうためです。PKCE 付きの認可コード フローを使用すれば、クライアント シークレットなしで安全にアクセス トークンを取得できます。機密アプリ（Web サーバー）の場合は、クライアント ID とクライアント シークレットをサーバー側に保存し、ユーザーに露出しないようにしてください。

リダイレクト URI の役割は何ですか？また、アプリの登録と一致させる必要があるのはなぜですか？

リダイレクト URI は、ID プロバイダーが認可応答（コードまたはトークン）を送信する宛先です。認可応答の乗っ取りを防ぐため、アプリの登録で設定したリダイレクト URI と一致している必要があります。プロバイダーが定める完全一致または許可されたパターンを使用してください。不一致があると、トークンの交換に失敗します。

ユーザーに認証を行わせ、アクセス トークンに加えて ID トークンを受け取るには、どうすればよいですか？

ID トークンを受け取るには、openid スコープを要求し、ID トークンの発行をトリガーする response_type を指定します（openid を伴う認可コード フロー）。ID トークンには、認証されたユーザーの ID に関するクレームが含まれます。ID トークンはクライアント アプリへのサインインに使用し、アクセス トークンは後続の API の呼び出しに使用してください。

Web アプリと単一ページ アプリ (SPA) では、それぞれどの認可フローを使用しますか？

従来型の Web アプリケーション（サーバー側）では、通常、クライアント ID とクライアント シークレットを使用する認可コード フローを採用し、Web サーバー上でコードをトークンと交換します。単一ページ アプリは、クライアント シークレットを使わず、PKCE を用いた認可コード付与を使用します。デスクトップ アプリも PKCE を使用します。アプリの種類と、シークレットを安全に保管できる場所に応じてフローを選択してください。

1 つのアプリ登録を複数のクライアント アプリで使い回すことはできますか。それとも、アプリごとにアプリ登録を作成すべきですか？

同じ構成とリダイレクト URI を共有するのであれば、1 つのアプリ登録を複数のクライアント アプリで使用することはできます。ただし、アクセス許可、リダイレクト URI、ライフサイクル管理を分離するため、一般的には用途の異なるアプリごとに別々のアプリ登録を作成することがベスト プラクティスとされています。アプリが異なるアクセス許可スコープや管理者の同意の動作を必要としないかを検討してください。

Web サーバーや API でトークンを検証するには、どうすればよいですか？

Web サーバーや API では、アクセス トークンまたは ID トークンの署名、発行者、対象ユーザー（アプリ ID またはアプリケーション ID）、有効期限を検証する必要があります。署名キーを取得するには、プロバイダーの検出ドキュメントを使用し、お使いのプラットフォームに推奨される検証ライブラリに従ってください。検証により、認証と認可を受けたアプリケーションからの要求のみが受け入れられるようになります。

クライアント資格情報を使用して、バックエンド サービス向けのアクセス トークンを要求するには、どのような手順が必要ですか？

サーバー間のシナリオでは、Azure アプリを登録し、アプリケーション許可を付与したうえで、クライアント資格情報フローを使用します。トークン エンドポイントに対して、grant_type=client_credentials、client_id、client_secret、scope または resource を指定して POST を送信します。トークン エンドポイントは、バックエンドが Microsoft のサービスや保護された API を呼び出すために使用できるアクセス トークンを返します。

マルチテナント アプリケーションで OAuth の同意と管理者の同意を処理するには、どうすればよいですか？

アプリをマルチテナントとして登録している場合、認可要求の中で他のテナントのユーザーが委任されたアクセス許可に同意できます。管理者の同意が必要なアクセス許可については、管理者が自身のテナントに対して同意を付与する必要があります。テナント管理者が大規模に OAuth の同意を付与できるよう、手順と同意用 URL を案内に含めてください。

認可要求が失敗した場合、どのようなトラブルシューティングを行うべきですか？

Microsoft のポータルにアプリが登録されていること、リダイレクト URI が一致していること、クライアント ID とシークレットが正しいこと、スコープが有効であること、そして（使用している場合）付与の種類と PKCE のパラメーターが正しいことを確認してください。認可エンドポイントやトークン エンドポイントが返すエラー メッセージを確認し、クライアント側とサーバー側の両方のログを調べます。特定のエラー コードについては、Stack Overflow やプロバイダーのドキュメントが参考になります。

登録済みのアプリに Google カレンダーなどのサードパーティ API を統合するには、どうすればよいですか？

Google カレンダーやその他のサードパーティ API を統合するには、それらのプロバイダーが求める OAuth 2.0 認可フローを実装する必要があります。アプリは、サードパーティ API に必要な正しいスコープを要求し、トークンのライフサイクルをそれぞれ個別に扱わなければなりません。各プロバイダーに対して個別のクライアント アプリ登録が必要になる場合があり、各サービスのアクセス トークンの取得を調整する必要があります。

デバイス コード フローなど、特定のデバイス向けの特殊なフローはいつ使用すればよいですか？

ブラウザーが利用できない、入力手段が限られたデバイスには、デバイス コード フローを使用します。デバイス コード フローでは、ユーザーが別のデバイスで確認用 URL にアクセスして認証を行えます。これは、認可コード付与、クライアント資格情報、更新トークンの各フローと並んで利用できる特殊な認可フローの 1 つで、さまざまな種類のアプリケーション形態に対応するために用意されています。