Реализация аутентификации токена

Question

Какие шаги я должен выполнить, чтобы реализовать аутентификацию токена на моей веб-странице?

Любое резюме или ссылки будут оценены.

Я хочу реализовать аналог Facebook или Google, впервые войти в систему клиента и получить токен, а затем использовать его в следующих действиях. Я также читал об OAuth, но не хочу предоставлять доступ к своему приложению от третьих лиц.

---

Спасибо за длинный ответ, и мне кажется, мне нужно больше об этом читать.

То, что я хочу, это знать «шаги» для реализации базового веб-приложения, использующего аутентификацию токена. То есть пользователь входит в систему один раз, а затем может выполнять некоторые действия: добавлять контент, редактировать и т. Д.

Я знаю, что то, что я говорю, похоже на сеанс, где сервер добавляет SESSION_ID в заголовок HTML, и более поздний запрос идентифицируется и связывается с этим сеансом. Я читаю, что сессии не очень хорошо масштабируются, поэтому я хочу внедрить аналогичную систему, такую ​​как gmail или facebook, прежде чем они перейдут в OAuth. Возможно, я говорю о чем-то похожем на oauth (я не читаю очень подробно), но с двумя ногами вместо трех ног.

Answer 1

Вы должны подумать о своих требованиях, выбрать подходящий протокол и какое-нибудь приличное программное обеспечение, которое его реализует.

Трудно сказать больше без подробностей:

• являютсяВы говорите об аутентификации для одного или нескольких веб-приложений?Вам нужен единый вход между различными веб-приложениями?
• должны ли все пользовательские данные храниться на вашем сервере или пользователь должен иметь возможность войти, например, с помощью учетной записи Google?
• должен ли токен содержать информациюо пользователе?
• на какой платформе разрабатываются ваши приложения?
• какой метод аутентификации следует использовать?
• вы хотите реализовать портал?

Существует очень широкий спектр протоколов и инструментов, которые могут или не могут соответствовать вашим требованиям:

http://en.wikipedia.org/wiki/Category:Authentication_methods

http://en.wikipedia.org/wiki/Category:Identity_management_systems

Я личнонапример, CAS (http://www.jasig.org/cas) для единого входа на основе токенов между несколькими веб-приложениями. Он основан на Java, но также имеет некоторую поддержку PHP и .Net.

OpenID хорошо, если вы хотите, чтобы пользователи могливойдите в систему с помощью Google, Yahoo, любой учетной записи (настраиваемой ...) и не хотите самостоятельно хранить информацию о пользователе.

Kerberos / SPNEGO - это то, что вам нужно, если вы хотите иметь встроенную Windows-SSO.для корпоративных приложений интранета.

Для университетских приложений лучше всего подойдет SAML / Shibboleth.За пределами университетов он несколько менее популярен, возможно, потому, что это довольно сложный протокол.

Да, и я почти забыл: у большинства веб-фреймворков / стандартов есть собственная версия старой "аутентификации на основе форм".При переходе пользователя в форму входа в систему вводятся его имя пользователя и пароль.Оба с SSL или без SSL транспортируются на веб-сервер / сервер приложений.Сервер проверяет его по какой-либо базе данных и дает пользователю файл cookie, который передается и проверяется каждый раз, когда пользователь отправляет запрос.Но помимо всех этих блестящих протоколов это кажется довольно скучным: -)

И прежде чем делать что-либо с веб-аутентификацией, вы можете немного подумать о веб-безопасности в целом (http://journal.paul.querna.org/articles/2010/04/11/internet-security-is-a-failure/ http://www.eff.org/files/DefconSSLiverse.pdf) и что вы можете сделать, чтобы на вашем сайте не стало еще хуже (http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf).

Answer 2

вижу вашу точку зрения.

На уровне протокола очень упрощенный подход с использованием токенов - базовая аутентификация HTTP.Но это часто не подходит, так как нет функции выхода из системы и т. Д.

Пользовательский простой подход на основе файлов cookie может выглядеть, например, так:

• Сервер генерирует какой-то видof secret (значение, которое трудно угадать)
• Когда пользователь пытается получить доступ к защищенному ресурсу, он перенаправляется в форму входа
• , после успешной аутентификации он получает cookie.Этот файл cookie содержит три значения: имя пользователя, временную метку и хэш {username server-secret timestamp}.
• . При каждом запросе пользователя сервер пересчитывает значения хеш-функции и сравнивает его со значением, которое клиент отправляет в своем файле cookie.

(необходимо больше учитывать: флаг httponly и безопасности, безопасность транспортного уровня, атаки воспроизведения и т. Д.)

Amazon S3 сохраняет свой токен аутентификации в заголовке HTTP и использует HMAC для его вычисления,Это описано здесь: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?S3_Authentication.html (не обязательно рекомендуется для использования с веб-приложением на основе браузера)

Если поблизости есть книга о REST, вы можете посмотреть, есть ли в ней глава об аутентификации,Вероятно, здесь все объясняется гораздо лучше, чем здесь: -)

Существуют некоторые фреймворки, способные выполнять аутентификацию такого рода.По соображениям безопасности имеет смысл сначала проверить их, прежде чем реализовывать свои собственные.