アカウント名とメールアドレスの両方で認証したい〜利用者への説明をさぼりたい〜

2026年01月14日 水曜日


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

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

「アカウント名とメールアドレスの両方で認証したい〜利用者への説明をさぼりたい〜」のイメージ

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

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

ここではuser@example.comなどのメールアドレス形式とuserのようなアカウント名の両対応でBASIC認証したい方に、ngx_auth_modの新機能の用途を解説します。

メールアドレスとアカウント名のどちらでも認証したい理由には、以下のようなものがあります。

  • メールアドレスで入力するのか、アカウント名で入力するのか利用者に説明したくない。
  • サイト毎に認証のアカウント形式がバラバラで、利用者が混乱してるのを軽減したい。
認証がカオスなイメージ

メールアドレスのローカル部(@より前)の部分にはアカウント名が含まれているので、メールアドレスだけを選んでアカウント名を抽出すれば、アカウント名に統一できます。

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

この選択と抽出の処理をngx_rewrite_switch_authにさせれば、アカウント名での認証ロジックを流用して、アカウント名とメールアドレスでの両方に1つの認証で対応できます。

複数認証のイメージ

つまり、ngx_rewrite_switch_authを使うことで、アカウント名の認証モジュールを利用して、アカウント名とメールアドレスの両方で認証できるようになります。

解決したイメージ


設定手順の概略

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

このアカウント名とメールアドレスでの両方の認証に対応する方法を、以下の順で説明します。

  1. アカウント名での認証を準備する
  2. アカウント名での認証をテストする
  3. ngx_rewrite_switch_authを設定する
  4. nginxで利用する
  5. (必要ならば)nginxで認証結果をキャッシュ

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

構成例

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

1. アカウント名での認証を準備する

構成例1

ngx_http_auth_request_module用のアカウント名で認証するモジュールを、http://127.0.0.1:9200で動かします。
ngx_auth_modについては、ngx_auth_modの「はじめに」で基本的な設定方法を書いているので、参考にしてください。

2. アカウント名での認証をテストする

構成例2

nginxの動作確認用に、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;

        ...
    }

    ...

アカウント名で認証できることを確認します。

3. ngx_rewrite_switch_authを設定する

構成例3

ngx_rewrite_switch_authに、アカウント名とメールアドレスにマッチする2つの正規表現で、処理を変える設定をします。

以下は、この内容でのngx_rewrite_switch_auth設定例です。

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

[[switch]]
username_re = '^[^@]+$' # アカウント名の正規表現
auth_url = "http://127.0.0.1:9200"
set_username = "$u" # $uには受け取ったアカウント名が設定される
set_password = "$p" # $pには受け取ったパスワードが設定される

[[switch]]
username_re = '^([^@]+)@example\.com$' # メールアドレスの正規表現
auth_url = "http://127.0.0.1:9200"
set_username = "$1" # アカウント名を取り出して渡す
set_password = "$p"

この設定例で利用しているパラメータごとに、設定内容の概要を説明しておきます。パラメータ自体の詳細については、ngx_rewrite_switch_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認証の認証領域名(“Multi Authentication”)
[[switch]]username_re メールアドレスからローカル部を取り出す正規表現(取得したアカウント名は$1に保存)
[[switch]]auth_url アカウント名用認証モジュールのURL
[[switch]]set_username リクエストから入力されたのがアカウント名($u)であればそのまま、メールアドレスであれば取り出したアカウント名($1)を渡す
[[switch]]set_password リクエストから受け取ったパスワード($p)をそのまま渡す

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

4. nginxで利用する

構成例4

ngx_http_auth_request_moduleの呼びだし先をngx_rewrite_switch_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とブラウザを再起動してから、メールアドレスとアカウント名の両方で認証できることを確認します。

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

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


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

複数形式対応の認証を手軽に構築して、より楽な認証ライフを!

ヒラマツ

2026年01月14日 水曜日

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

Related
関連記事