Основное отличие состоит в том, что для этого не требуется отправлять имя пользователя и пароль по сети в виде открытого текста. Он также невосприимчив к повторным атакам, поскольку использует одноразовый номер с сервера.
Сервер предоставляет клиенту одноразовый номер использования (одноразовый номер), который он объединяет с именем пользователя, областью, паролем и запросом URI. Клиент запускает все эти поля с помощью метода хеширования MD5 для создания хеш-ключа.
Он отправляет этот хэш-ключ на сервер вместе с именем пользователя и областью для попытки аутентификации.
На стороне сервера тот же метод используется для генерации хеш-ключа, только вместо того, чтобы использовать пароль, введенный в браузер, сервер ищет ожидаемый пароль для пользователя из своей пользовательской БД. Он ищет сохраненный пароль для этого имени пользователя, запускает по тому же алгоритму и сравнивает его с тем, что отправил клиент. Если они совпадают, то доступ предоставляется, в противном случае он может отправить обратно 401 Несанкционированный (без входа в систему или неудачный вход в систему) или 403 Запрещенный (доступ запрещен).
Дайджест-аутентификация стандартизирована в RFC2617 . Вот хороший обзор в Википедии :
Вы можете думать об этом так:
- Клиент делает запрос
- Клиент возвращает одноразовый номер с сервера и запрос аутентификации 401
- Клиент отправляет обратно следующий массив ответов (имя пользователя, область, generate_md5_key (nonce, имя пользователя, область, URI, password_given_by_user_to_browser)) (да, это очень упрощенно)
- Сервер принимает имя пользователя и область (плюс он знает URI, запрашиваемый клиентом) и ищет пароль для этого имени пользователя. Затем он идет и делает свою собственную версию generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
- Он сравнивает выходные данные generate_md5 (), полученные с отправленным клиентом, если они совпадают с тем, что клиент отправил правильный пароль. Если они не совпадают, отправленный пароль был неверным.