ApacheでOpenID Connect認証を実現!mod_auth_openidcの設定方法を徹底解説

OpenID Connectは、OAuth 2.0をベースとしたシングルサインオン(SSO)およびアイデンティティ層の標準規格であり、WebアプリケーションやAPIへの安全なユーザー認証を実現します。多くの企業やサービスで導入されており、利便性とセキュリティを両立できる点が特徴です。

Apache HTTPサーバーは、多くのWebサービスで利用される堅牢なWebサーバーであり、モジュールの追加によって多様な機能を持たせることが可能です。その中でも「mod_auth_openidc」は、ApacheにOpenID Connect認証機能を追加するためのモジュールです。これにより、既存のApache環境でも容易にOpenID Connectを導入でき、外部のIDプロバイダー(Google, Microsoft Azure AD, Keycloakなど)と連携したユーザー認証が実現します。

本記事では、Apacheサーバーにmod_auth_openidcを導入し、OpenID Connectによる認証フローを構築する方法について解説します。mod_auth_openidcのインストールから設定、動作確認までをステップバイステップで説明し、認証フローの仕組みやトラブルシューティングについても詳しく解説します。これにより、Apacheを利用した安全なユーザー認証環境の構築が可能になります。

目次

mod_auth_openidcとは


mod_auth_openidcは、Apache HTTPサーバーにOpenID Connect (OIDC) 認証を実装するためのモジュールです。OIDCはOAuth 2.0の拡張プロトコルで、ユーザー認証とシングルサインオン(SSO)を可能にします。mod_auth_openidcを導入することで、Apacheをリバースプロキシやアプリケーションサーバーとして利用しながら、外部のIDプロバイダーを介した認証が簡単に実現できます。

主な特徴

  • シングルサインオン(SSO)対応:一度のログインで複数のサービスにアクセス可能になります。
  • 外部IDプロバイダーとの連携:Google, Microsoft Azure AD, Keycloak, Auth0など、多様なIDプロバイダーと連携可能です。
  • セッション管理:OIDCのトークンを利用してセッションを管理し、ユーザーの再認証を不要にします。
  • 柔軟なアクセス制御:特定のディレクトリやリソースへのアクセスを、ユーザーの属性やグループごとに制限可能です。

動作の仕組み

  1. ユーザーがApacheサーバーにアクセスします。
  2. mod_auth_openidcがユーザーをOIDCプロバイダーの認証ページにリダイレクトします。
  3. 認証が成功すると、OIDCプロバイダーはアクセストークンやIDトークンを発行します。
  4. mod_auth_openidcがトークンを受け取り、ユーザーの属性情報をApacheの環境変数に格納します。
  5. Apacheは、受け取ったトークンを基にリクエストを処理し、適切にアクセスを許可または拒否します。

mod_auth_openidcは、セキュリティと利便性のバランスを保ちながら、Webアプリケーションに簡単に統合できる強力なツールです。次章では、mod_auth_openidcの具体的なインストール方法について解説します。

Apacheでのmod_auth_openidcインストール方法

mod_auth_openidcをApacheに導入するには、必要なパッケージをインストールし、Apacheのモジュールとして有効化する必要があります。以下では、主要なLinuxディストリビューションにおけるインストール手順を解説します。

前提条件

  • Apache HTTPサーバーがインストール済みであること
  • rootまたはsudo権限を持つユーザーで操作できること
  • OpenSSLがインストールされていること

インストール手順

1. 必要なパッケージのインストール

CentOS / RHEL 系

sudo yum install epel-release
sudo yum install mod_auth_openidc

Ubuntu / Debian 系

sudo apt update
sudo apt install libapache2-mod-auth-openidc

インストールが完了すると、mod_auth_openidcが自動的にApacheモジュールとして追加されます。

2. Apacheモジュールの有効化


Ubuntu / Debian系では、モジュールを有効化するために以下のコマンドを実行します。

sudo a2enmod auth_openidc


CentOSやRHEL系では、自動的に有効になりますが、念のためApacheの設定ファイルを確認し、以下の行があることを確認してください。

LoadModule auth_openidc_module modules/mod_auth_openidc.so

3. Apacheの再起動


モジュールを有効化した後は、Apacheを再起動して変更を反映させます。

sudo systemctl restart httpd  # CentOS / RHEL
sudo systemctl restart apache2  # Ubuntu / Debian

インストール確認


以下のコマンドでmod_auth_openidcが正しくインストールされ、有効になっているか確認します。

apachectl -M | grep openidc


出力にauth_openidc_moduleが表示されれば、インストールは成功です。

次章では、OpenID Connectプロバイダーの設定方法について解説します。

OpenID Connectプロバイダーの選定と準備

OpenID Connect (OIDC) 認証をApacheで実現するためには、外部のOIDCプロバイダー(IdP:Identity Provider)を利用します。プロバイダーはユーザーの認証を担当し、Apacheと連携してアクセス制御を行います。ここでは、代表的なOIDCプロバイダーの選定基準と、基本的な準備手順を解説します。

代表的なOpenID Connectプロバイダー

  • Google:個人ユーザーから企業まで幅広く対応。Googleアカウントを利用したSSOが可能です。
  • Microsoft Azure Active Directory (Azure AD):企業向け。Active Directoryと統合でき、エンタープライズ環境に最適です。
  • Keycloak:オープンソースのIDプロバイダー。オンプレミスやクラウドでホスティング可能で、カスタマイズ性が高いです。
  • Auth0:開発者向けで、簡単にOIDCを導入できるクラウドサービスです。

プロバイダー選定のポイント

  • 導入の容易さ:プロバイダーの管理インターフェースが分かりやすく、セットアップが容易であること。
  • カスタマイズ性:ユーザー属性やロールを細かく設定できるかどうか。
  • サポート体制:障害時のサポートが充実しているか。
  • コスト:無料枠や使用量に応じた料金プランがあるか。

OIDCプロバイダーでの事前準備


プロバイダーを選定したら、以下の手順でOIDCアプリケーションを登録します。

1. アプリケーション登録


OIDCプロバイダーの管理画面で新規アプリケーションを登録します。

  • リダイレクトURIhttps://your-apache-server/callbackなど、Apacheがトークンを受け取るエンドポイントを指定します。
  • スコープ設定openid profile emailなど、必要な情報を要求するスコープを設定します。

2. クライアントIDとシークレットの取得


アプリケーション登録後、OIDCプロバイダーからクライアントIDクライアントシークレットが発行されます。これはApacheの設定で必要になりますので、安全に保管してください。

3. ユーザーとグループの設定


必要に応じて、認証を許可するユーザーやグループをOIDCプロバイダー側で設定します。アクセス制御ポリシーや属性情報を細かく設定できるプロバイダーを選ぶと、より柔軟な制御が可能です。

設定例(Keycloakの場合)

  1. Keycloak管理画面にログインし、新しいレルム(Realm)を作成。
  2. クライアント設定で「公開」クライアントとしてApache用アプリケーションを登録。
  3. リダイレクトURIやロールマッピングを行い、クライアントシークレットを取得。

次章では、Apacheの設定ファイルを編集し、OIDCプロバイダーと連携する方法を解説します。

Apache設定ファイルの編集(基本設定)

mod_auth_openidcをインストールし、OIDCプロバイダーの準備が整ったら、Apacheの設定ファイルを編集して、OpenID Connect認証を有効にします。ここでは、基本的な設定例を示し、ApacheがOIDCプロバイダーと連携できるようにします。

設定ファイルの場所


Apacheの設定ファイルはディストリビューションによって異なりますが、一般的には以下のいずれかです。

  • CentOS/RHEL系/etc/httpd/conf.d/ディレクトリ内
  • Ubuntu/Debian系/etc/apache2/sites-available/または/etc/apache2/conf-available/

必要に応じて、新しい設定ファイルを作成するか、既存の設定ファイルを編集します。

設定例(基本構成)


以下は、Apacheの特定のディレクトリに対してOIDC認証を適用するシンプルな設定例です。

<VirtualHost *:443>
    ServerName your-apache-server.com
    DocumentRoot /var/www/html

    # TLS設定(省略可能、既存のSSL設定を利用)
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/server.crt
    SSLCertificateKeyFile /etc/pki/tls/private/server.key

    # OIDC設定
    OIDCProviderMetadataURL https://idp.example.com/.well-known/openid-configuration
    OIDCClientID your-client-id
    OIDCClientSecret your-client-secret
    OIDCRedirectURI https://your-apache-server/callback

    # セッション管理
    OIDCCryptoPassphrase my-secret-passphrase

    # 認証対象ディレクトリ
    <Location /secure>
        AuthType openid-connect
        Require valid-user
    </Location>

</VirtualHost>

設定項目の解説

  • OIDCProviderMetadataURL:OIDCプロバイダーのメタデータURL。これによりプロバイダーのエンドポイントが自動的に設定されます。
  • OIDCClientID/OIDCClientSecret:プロバイダーから発行されたクライアントIDとシークレットを設定します。
  • OIDCRedirectURI:認証後にリダイレクトされるURIで、OIDCプロバイダーに事前登録したURLと一致させる必要があります。
  • OIDCCryptoPassphrase:セッションを暗号化するためのパスフレーズを設定します。任意の文字列を指定してください。
  • AuthType openid-connect:該当ディレクトリへのアクセス時にOIDC認証を要求します。
  • Require valid-user:認証が成功したユーザーのみアクセスを許可します。

Apacheの再起動


設定ファイルを保存したら、Apacheを再起動して設定を反映させます。

sudo systemctl restart httpd  # CentOS/RHEL
sudo systemctl restart apache2  # Ubuntu/Debian

次章では、OIDCプロバイダーから取得したクライアントIDとシークレットの設定方法について詳しく解説します。

クライアントIDとシークレットの設定

OpenID Connect (OIDC) 認証をApacheで動作させるためには、OIDCプロバイダーから発行された「クライアントID」と「クライアントシークレット」を正しく設定する必要があります。これらの情報は、Apacheが認証リクエストをプロバイダーに送信し、ユーザーを識別する際に使用されます。

クライアントIDとシークレットの取得方法

Googleの場合

  1. Google Cloud Consoleにアクセス。
  2. 新しいプロジェクトを作成または既存プロジェクトを選択。
  3. 「APIとサービス」→「認証情報」に移動。
  4. 「認証情報を作成」→「OAuth クライアントID」を選択。
  5. アプリケーションタイプは「ウェブアプリケーション」を選択。
  6. リダイレクトURIhttps://your-apache-server/callbackを指定。
  7. 作成後、クライアントIDとシークレットが発行されます。

Keycloakの場合

  1. Keycloakの管理コンソールにログイン。
  2. 新規レルムを作成または既存レルムを選択。
  3. 「クライアント」セクションで「新規クライアント」を作成。
  4. クライアントIDを任意に設定し、OIDC認証フローを選択。
  5. リダイレクトURIにhttps://your-apache-server/callbackを入力し保存。
  6. クレデンシャルタブからクライアントシークレットを取得します。

Apacheへの設定


取得したクライアントIDとシークレットは、Apacheの設定ファイルに以下のように記述します。

OIDCClientID your-client-id
OIDCClientSecret your-client-secret

これらの設定は、ApacheのVirtualHostセクション内に配置されます。

<VirtualHost *:443>
    ServerName your-apache-server.com
    DocumentRoot /var/www/html

    OIDCProviderMetadataURL https://idp.example.com/.well-known/openid-configuration
    OIDCClientID abc123xyz
    OIDCClientSecret s3cr3tK3y987
    OIDCRedirectURI https://your-apache-server/callback

    <Location /secure>
        AuthType openid-connect
        Require valid-user
    </Location>

</VirtualHost>

セキュリティ対策

  • クライアントシークレットは、絶対に外部に漏れないように注意してください。
  • 設定ファイルのパーミッションを制限し、rootユーザーのみが編集可能な状態にします。
sudo chmod 600 /etc/httpd/conf.d/oidc.conf
  • クライアントシークレットのローテーションを定期的に実施し、セキュリティを維持します。

次章では、設定が正しく機能しているかを確認する動作テストと認証フローについて解説します。

認証フローの確認と動作テスト

mod_auth_openidcの設定が完了したら、Apacheが正しくOIDC認証を処理できるか動作テストを行います。この段階では、ユーザーがApacheサーバー経由で保護されたリソースにアクセスし、OIDCプロバイダーを通じて認証されるフローを確認します。

動作テストの手順

1. Apacheを再起動


設定が完了したら、Apacheを再起動して新しい設定を反映させます。

sudo systemctl restart httpd  # CentOS/RHEL
sudo systemctl restart apache2  # Ubuntu/Debian

2. ブラウザでアクセス


ブラウザを使用して、保護されたリソースにアクセスします。

https://your-apache-server/secure  
  • 初回アクセス時にはOIDCプロバイダーのログイン画面にリダイレクトされます。
  • ユーザー名とパスワードを入力して認証を行います。

3. 認証後のリダイレクト確認


認証が成功すると、OIDCプロバイダーからhttps://your-apache-server/callbackにリダイレクトされます。

  • 正常にリソース(例:/secure)にアクセスできる場合は、認証フローが正しく機能しています。
  • 認証に失敗する場合や、リダイレクトが行われない場合は設定ファイルを再度確認してください。

ログを確認する


動作テスト中に問題が発生した場合は、Apacheのエラーログおよびmod_auth_openidcのデバッグログを確認します。

sudo tail -f /var/log/httpd/error_log  # CentOS/RHEL
sudo tail -f /var/log/apache2/error.log  # Ubuntu/Debian


エラーログに以下のようなエントリがある場合は、設定に問題がある可能性があります。

[auth_openidc:error] [pid 12345] [client 192.168.0.1:54321] oidc_authenticate_user: OIDCProviderMetadataURL not reachable


→ プロバイダーのURLやネットワーク接続を確認してください。

動作確認のポイント

  • リダイレクトURLの不一致:OIDCプロバイダーに登録したリダイレクトURIが正しいか確認します。
  • クライアントID/シークレットの不一致:Apache設定ファイルとOIDCプロバイダー側の設定が一致しているか確認します。
  • SSL証明書エラー:OIDCプロバイダーがSSLを使用している場合は、Apacheサーバーが正しい証明書で通信していることを確認します。

成功時の動作

  • 認証後、/secureにアクセス可能となり、OIDCプロバイダーから返されたトークン情報が$_SERVER変数に格納されます。
  • ユーザー名やメールアドレスなどの属性情報はApache環境変数として利用できます。
OIDCRemoteUserClaim preferred_username
OIDCUserInfoClaim preferred_username REMOTE_USER


これにより、認証ユーザーの情報をログやアプリケーション内で活用できます。

次章では、認証が失敗した場合のエラーと対処法について詳しく解説します。

トラブルシューティングとよくあるエラー対処法

mod_auth_openidcを使用したOpenID Connect (OIDC) 認証では、設定ミスや通信エラーが原因で認証が失敗することがあります。ここでは、よくあるエラーとその解決方法について解説します。

1. 認証フローが開始されない


エラー例:

[auth_openidc:error] oidc_authenticate_user: OIDCProviderMetadataURL not reachable


原因:

  • OIDCプロバイダーのメタデータURLが正しく設定されていない
  • ネットワーク接続エラーやDNSの問題

解決方法:

  1. OIDCProviderMetadataURLのURLが正しいか確認します。
  2. プロバイダーのメタデータURLにブラウザから直接アクセスし、JSONが返ってくるか確認します。
  3. サーバーのDNS設定やプロキシ設定を確認し、適切に通信できる状態を確保します。
curl https://idp.example.com/.well-known/openid-configuration

2. 認証後に「403 Forbidden」が表示される


原因:

  • Require valid-user が設定されているが、ユーザー情報が取得できていない
  • Apacheがユーザー属性情報を正しく解釈できていない

解決方法:

  1. OIDCRemoteUserClaimの設定を確認し、OIDCプロバイダーが返すクレーム名が一致しているかを確認します。
OIDCRemoteUserClaim email
  1. OIDCUserInfoClaimで正しいユーザークレームを指定します。
OIDCUserInfoClaim preferred_username REMOTE_USER
  1. トークン内のクレームを確認するには以下を実行します。
sudo tail -f /var/log/apache2/error.log


OIDCプロバイダーのレスポンス例:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john.doe@example.com"
}

3. 認証後に「500 Internal Server Error」が発生する


原因:

  • セッションの暗号化に必要なOIDCCryptoPassphraseが未設定
  • クライアントシークレットが誤っている

解決方法:

  1. Apache設定に以下を追加して、セッション暗号化のパスフレーズを設定します。
OIDCCryptoPassphrase my-secret-passphrase
  1. クライアントIDとシークレットを再確認し、正しく記述されているかチェックします。

4. リダイレクトループが発生する


原因:

  • リダイレクトURIの不一致
  • トークンの検証が失敗している

解決方法:

  1. OIDCプロバイダー側で登録したリダイレクトURIがOIDCRedirectURIと一致していることを確認します。
OIDCRedirectURI https://your-apache-server/callback
  1. トークンの有効期限切れやシグネチャエラーが発生していないかログを確認します。
[auth_openidc:error] oidc_validate_jwt: JWT validation failed
  1. 時刻のズレが原因でトークンが無効化される場合があるため、サーバーのNTP設定を確認します。
sudo timedatectl set-ntp true

5. クレデンシャルエラー(invalid_client)


エラー例:

[auth_openidc:error] oidc_handle_authorization_response: invalid_client


原因:

  • クライアントIDまたはクライアントシークレットが正しくない

解決方法:

  • OIDCプロバイダーで発行されたクライアントIDとシークレットを再確認し、設定ファイルに正確に記述します。
OIDCClientID abc123xyz
OIDCClientSecret s3cr3tK3y987

ログレベルを上げてデバッグ


トラブルシューティングの際は、ログレベルをデバッグモードに設定することで詳細な情報を確認できます。

LogLevel auth_openidc:debug


再起動後にエラーログを確認し、詳細な情報を取得します。

sudo systemctl restart apache2
sudo tail -f /var/log/apache2/error.log

次章では、応用設定として特定のディレクトリやページに対して細かくアクセス制御を行う方法を解説します。

応用設定(認可制御や特定ページの制限)

mod_auth_openidcを使用すると、OpenID Connect (OIDC) 認証後のユーザー情報(クレーム)を活用して、特定のリソースやディレクトリへのアクセス制御を柔軟に設定できます。これにより、ユーザーグループやロールに応じた細かいアクセス制限を実現可能です。ここでは、応用的な設定方法を解説します。

1. 特定グループのユーザーのみアクセスを許可


OIDCプロバイダーがユーザーの所属グループ情報を返す場合、その情報を基に特定のグループに属するユーザーだけがアクセス可能なディレクトリを作成できます。

<VirtualHost *:443>
    ServerName your-apache-server.com
    DocumentRoot /var/www/html

    OIDCProviderMetadataURL https://idp.example.com/.well-known/openid-configuration
    OIDCClientID your-client-id
    OIDCClientSecret your-client-secret
    OIDCRedirectURI https://your-apache-server/callback

    OIDCCryptoPassphrase my-secret-passphrase
    OIDCRemoteUserClaim email

    <Location /admin>
        AuthType openid-connect
        Require claim groups:admin
    </Location>
</VirtualHost>

ポイント:

  • Require claim groups:admin は、OIDCプロバイダーが返すgroupsクレームにadminが含まれるユーザーのみアクセスを許可します。
  • グループ情報がトークン内に含まれていることを事前に確認してください。

2. 特定のユーザーだけがアクセス可能なページ


ユーザー単位でアクセスを制限したい場合は、以下のようにemailクレームを使って認可を設定します。

<Location /secure-page>
    AuthType openid-connect
    Require claim email user1@example.com user2@example.com
</Location>

解説:

  • user1@example.comuser2@example.comだけが/secure-pageにアクセス可能になります。
  • 複数のユーザーをスペースで区切って設定可能です。

3. 認可ポリシーを複数条件で設定


グループ情報とメールアドレスの両方を条件にする場合は、Requireディレクティブを複数指定します。

<Location /management>
    AuthType openid-connect
    Require claim groups:manager
    Require claim email boss@example.com
</Location>
  • managerグループに所属し、かつboss@example.comであるユーザーだけがアクセス可能です。
  • すべての条件を満たす必要があります。

4. アクセス拒否の設定


特定のユーザーやグループに対してアクセスを拒否する場合は、Require notディレクティブを使用します。

<Location /restricted>
    AuthType openid-connect
    Require not claim email intruder@example.com
</Location>

この設定により、intruder@example.com/restrictedへのアクセスを拒否されます。

5. カスタムエラーページの設定


認証や認可に失敗した場合に、カスタムのエラーページを表示することができます。

ErrorDocument 401 /error/unauthorized.html
ErrorDocument 403 /error/forbidden.html
  • 認証失敗時は401 Unauthorized、認可失敗時は403 Forbiddenを表示します。
  • /error/unauthorized.html/error/forbidden.html はカスタムで作成したエラーページです。

6. セッションタイムアウトとリフレッシュトークンの設定


OIDCセッションの有効期限を制御することで、一定時間経過後に再認証を促すことができます。

OIDCSessionInactivityTimeout 900  # 15分
OIDCSessionMaxDuration 3600  # 1時間
  • OIDCSessionInactivityTimeout は非アクティブ状態が続いた場合にセッションが無効になる時間(秒)を指定します。
  • OIDCSessionMaxDuration はセッションの最大持続時間を設定します。

動作確認とテスト


設定後は、ブラウザで対象のディレクトリやページにアクセスし、条件に応じてアクセスが許可・拒否されることを確認します。エラーログを参照して、正しくアクセス制御が行われているかを確認してください。

sudo tail -f /var/log/apache2/error.log

次章では、全体のまとめと設定の最終確認について解説します。

まとめ

本記事では、Apacheサーバーにmod_auth_openidcを導入し、OpenID Connect (OIDC) 認証を構築する方法について解説しました。

以下の流れで、インストールから応用設定までを網羅しました。

  • mod_auth_openidcの概要と、OIDC認証の仕組み
  • Apacheへのmod_auth_openidcインストール方法と、必要なパッケージの導入
  • OIDCプロバイダーの設定と、クライアントIDおよびシークレットの取得
  • Apache設定ファイルの編集を通じたOIDC連携
  • 認証フローの動作確認とテスト方法
  • トラブルシューティングによるエラーの特定と解消
  • 応用的なアクセス制御による特定ユーザーやグループごとの認可設定

mod_auth_openidcは、Apache環境にセキュアで柔軟な認証機能を追加できる強力なモジュールです。OIDCプロバイダーとの連携により、SSOや多要素認証(MFA)を容易に実現でき、エンタープライズ環境においても活用できます。

正しく設定を行うことで、アプリケーションのセキュリティと利便性が向上し、安全なユーザーアクセス管理が可能となります。今後は、OIDCプロバイダー側でのロール管理やポリシー設定を強化し、より高度なアクセス制御に取り組むことをおすすめします。

コメント

コメントする

目次