Простая аутентификация на NGINX с помощью LUA

auth pam? Там же можно правами пользователей все разрулить… Пользователь без консоли может в nginx и ничего более, а остальные не авторизуются на nginx… Нет, ваш способ работает, но чем система проще, тем меньше точнее отказа.

«Хотя бы минимальная защита от перебора»

ssl_client_certificate /path/to/nginx/ssl/ca.crt;
ssl_verify_client on;

1. Несмотря на то, что функции вынесены в общий словарь, счётчики у каждого рабочего процесса будут свои. В документации к модулю lua написано о возможных подходах к разделению данных между рабочими процессами.
2. Крайне рекомендуется везде использовать локальные переменные. Глобальные переменные в случае nginx добавляют только проблем и всё равно не решают вопрос с разделением данных хотя бы даже между запросами одного рабочего процесса nginx. Для того, чтобы проверить ваш код имеется специальная утилита lua-releng, подготовленная разработчиком модуля lua для nginx.
3. В nginx есть встроенные функции для вычисления md5 и sha1. Для вашей задачи с криптографической точки зрения корректно использовать только функцию hmac_sha1 вместо манипуляций с конкатенацией строки для хэширования. Подробнее об этом будет ниже.
4. Функцию nvl можно заменить идиомой

   (val or default)

   , которая будет принимать значение default во всех случаях, когда val == nil либо val = false (и только тогда).
5. Чтение из файла — блокирующая операция, которая приостановит выполнение ВСЕХ запросов рабочим процессом. Сетевые операции, осуществляемые через специальное API косокетов в Nginx, напротив, не блокируют выполнение остальных запросов. Поэтому часто можно увидеть использование Redis или других БД из модулей lua в nginx.
6. «Токен» валиден в пределах тех же суток, в которые выдан. Это достаточно непрактично в окрестности полуночи. Вместо этого обычно открытым текстом записывают прямо в токен срок окончания действия и всю строку подписывают HMAC-ом. Пример реализации того же самого в nginx (но куки ставит отдельный сервер, это легко переделать).
7. Ваш код уязвим к атаке удлинением сообщения. Предположим, пользователь в прошлом имел доступ к некоторому сервису и получил токен в виде хэшсуммы из секретного ключа, юзерагента и даты. Тогда даже после смены пароля или отзыва доступа он может обойти аутентификацию, рассчитав удлинённый хэш от своего старого значения юзерагента + старой даты + требуемого для удлинения паддинга + текущей даты. Подставив в юзерагент всё кроме даты он пройдёт проверку. Вот поэтому нужно применять HMAC, а не конкатенацию строк, чтобы не наступать на грабли при использовании криптографических примитивов.