Решение для аутентификации RESTFul через HTTPS

в Интернете действительно много дискуссий по аутентификации REST Architecture, поэтому я думаю, что пришло время разместить решение в одном месте. Решение, которое звучит несколько нормально:

(Профессионалы безопасности, пожалуйста, прокомментируйте)

  1. Пользователь авторизуется под своим логином и паролем
  2. На сервере логин и пароль проверяются
  3. если учетные данные действительны, мы получаем уникальный идентификатор, смешивая временную метку с идентификатором пользователя. мы используем таблицу для сопоставления uniqueId->userid и делаем запись для уникального идентификатора, который мы только что сгенерировали, и идентификатора пользователя

  4. Кроме того, мы устанавливаем заголовок HTTP, скажем, идентификатор, содержащий уникальный идентификатор и идентификатор пользователя, с конкатенацией строк, подобной этой <uniqueId>#<userid>.

  5. При каждом запросе клиент должен предоставлять эту информацию,

  6. если запрос от клиента требует, чтобы мы определили, кем является клиент, чтобы мы могли проверить его разрешения, то мы делаем это:

получить заголовок http #,

если не содержит недействительного пользователя

если содержит проверку в базе данных, если сопоставление uniqueId->userid существует

если да, мы идентифицировали пользователя, иначе недействительный пользователь

Вся эта схема основана на HTTPS


person Noor    schedule 24.12.2011    source источник
comment
Я бы подумал об использовании чего-то уже существующего, например OpenID, вместо того, чтобы изобретать что-то новое.   -  person D.Shawley    schedule 24.12.2011


Ответы (1)


Я не думаю, что вам нужно такое сложное решение, если вы используете HTTPS. Вы даже можете попросить клиента передавать имя пользователя и пароль с каждым запросом. Пока клиент не скомпрометирован, проблем нет. И если он будет скомпрометирован, все решение в любом случае развалится.

В общем, я думаю, что большинство разработчиков заинтересованы в решении по протоколу HTTP, а не HTTPS. Но для этого есть уже проверенные решения вроде OpenID или OAuth.

person laurent    schedule 24.12.2011