メールアドレスでBASIC認証する〜ドメイン付きで認証したい〜

2026年01月14日 水曜日


【この記事を書いた人】
ヒラマツ

セキュリティ本部 セキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい!」とフラグを...。

「メールアドレスでBASIC認証する〜ドメイン付きで認証したい〜」のイメージ

認証をnginx用にちょっと弄れる機能〜認証だってrewriteしたい〜の続き記事です。

ngx_auth_mod開発者のヒラマツです。

ここではuser@example.comなどのメールアドレス形式でBASIC認証したい方に、ngx_auth_modの新機能の用途を解説します。

メールアドレスでの混乱イメージ

アカウント名での認証システムを導入している場合に、実は組織内の他のサイトの認証と同様にメールアドレス形式に揃えたいことがありませんか?
ngx_rewrite_authを使えば、アカウント名での認証システムを流用して、user@example.comのようなメールアドレス形式でBASIC認証が可能になります。

メールアドレスでのBASIC認証を一から実現しようとすると、メールアドレスのデータを用意するなどの手間がかかります。しかし、この手間は、ngx_rewrite_authで代行することが可能です。

メールアドレスのローカル部(@より前)の部分にはアカウント名が含まれているので、正規表現で抽出できます。

アカウント抽出のイメージ

この抽出処理をngx_rewrite_authにさせれば、アカウント名での認証ロジックを流用して、メールアドレス形式のBASIC認証が実現できます。

email認証のイメージ

つまり、従来のアカウント名で認証を実現していたモジュールは維持したまま、ngx_rewrite_authを間に差し込むことで組織内の他の認証サイトと同じ形式でユーザが認証できるようになります。

メールアドレスでの統一イメージ


設定手順の概略

以後はnginxでの具体的な設定を説明します。実際に使用する際に活用してください。

このメールアドレス形式で認証するためのngx_rewrite_auth利用方法を、以下の順で説明します。

  • 0. アカウント名での認証を準備
  • 1. アカウント名での認証テスト
  • 2. ドメイン部分を追加する設定
  • 3. メールアドレスでの認証の利用
  • 4. (必要ならば)nginxで認証結果をキャッシュ

この後の説明では、以下のような構成を想定して説明します。

構成例

利用する環境に合わせて、適宜読み替えてください。

0. アカウント名での認証を準備

構成例0

すでにある前提の、アカウント名で認証するngx_http_auth_request_module用認証モジュールが、http://127.0.0.1:9200として動いてる前提で話をします。

必要であれば、ngx_auth_modなどを使って準備してください。
ngx_auth_modであれば、ngx_auth_modの「はじめに」に基本的な設定方法を書いているので、参考にしてください。

1. アカウント名での認証テスト

構成例1

事前の動作確認として、nginxにアカウント名での認証(http://127.0.0.1:9200)を使う設定をします。

具体的には、nginxにngx_http_auth_request_moduleの設定が必要で、以下はその変更部分の例です。

    ...

    location = /auth {
        auth_request off;
        proxy_intercept_errors off;
        proxy_cache off;

        proxy_pass http://127.0.0.1:9200;
        proxy_http_version 1.1;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";

        ...

        internal;
    }

    location /private/ {
        auth_request /auth;
        proxy_cache off;

        ...
    }

    ...

設定ができたら、アカウント名で認証できることを確認します。

2. ドメイン部分を追加する設定

構成例2

次に、ngx_auth_modのngx_rewrite_authモジュールで、メールアドレスからアカウント名を抽出して、アカウント名の認証モジュールで利用する設定をします。

以下の設定で動かせば、http://127.0.0.1:9201で、ngx_rewrite_authモジュールがメールアドレスをアカウント名に変換してくれるようになります。

socket_type = "tcp"
socket_path = "127.0.0.1:9201"
cache_seconds = 15
neg_cache_seconds = 2
use_etag = true
auth_realm = "Email Authentication"

username_re = '^(.*)@example\.com$'
auth_url = "http://127.0.0.1:9200"

set_username = "$1"
set_password = "$p" # $pには受け取ったパスワードが設定される

この設定例で利用しているパラメータごとに、設定内容の概要を説明しておきます。パラメータ自体の詳細については、ngx_rewrite_authドキュメントを参照してください。

パラメータ名 概要
socket_typesocket_path TCPソケットの127.0.0.1:9201で機能を提供する
cache_seconds 認証成功時のキャッシュ期間(15秒)
neg_cache_seconds 認証失敗結果のキャッシュ期間(2秒)
use_etag ETagおよびIf-None-Matchヘッダーを使った検証を有効化(nginxがHTTPキャッシュの検証で利用)
auth_realm BASIC認証の認証領域名(“Email Authentication”)
username_re example.comドメインのメールアドレスからローカル部を取り出す正規表現(取り出したアカウント名は$1に保存)
auth_url アカウント名の認証をする認証モジュールのURL(http://127.0.0.1:9200)
set_username 正規表現で取り出したアカウント名($1)を渡す
set_password リクエストから受け取ったパスワード($p)をそのまま渡す

ngx_rewrite_authの起動は、ngx_auth_modの他のモジュールと同様でsystemdなどで行います。
具体的な起動方法についてはngx_auth_modの「はじめに」で紹介していますので、そちらを参照してください。

3. メールアドレスでの認証の利用

構成例3

ngx_http_auth_request_moduleの呼びだし先を、メールアドレスでの認証モジュール(ngx_rewrite_auth)に切り替えます。

そのために、nginxの設定に以下の変更をします。

  • 呼びだし先をhttp://127.0.0.1:9200からhttp://127.0.0.1:9201に変更

以下の設定例のように、proxy_passに指定されたURLを変えるだけです。

    ...

    location = /auth {
        auth_request off;
        proxy_intercept_errors off;
        proxy_cache off;

        proxy_pass http://127.0.0.1:9201;
        proxy_http_version 1.1;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";

        ...

        internal;
    }

    location /private/ {
        auth_request /auth;
        proxy_cache off;

        ...
    }

    ...

nginxとブラウザを再起動してから、メールアドレスで認証できることを確認します。
動作が確認できたら、メールアドレスでの認証の設定は完了です。

4. (必要ならば)nginxで認証結果をキャッシュ

認証処理が遅いようであれば、認証結果をキャッシュして、認証の負荷が下げられます。ですが、必須ではないため、認証結果のキャッシュ設定方法については応用編: nginxで認証結果をキャッシュしたい〜認証処理の負荷を下げたい〜で解説します。必要であれば、そちらを参照して設定してください。


設定手順の説明は以上です。

BASIC認証をカスタマイズして、ぜひ良いメールアドレス認証ライフを!

ヒラマツ

2026年01月14日 水曜日

セキュリティ本部 セキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい!」とフラグを...。

Related
関連記事