Дизайн Restful API с базовой HTTP-аутентификацией

Примечание. Я знаю, что есть МНОГО других вопросов StackOverflow, касающихся этой темы. Я прочитал многие из них, а также многие другие веб-сайты. У меня остались следующие вопросы.

Итак, я создаю REST API для нового продукта. В настоящее время API предназначен исключительно для частного использования нашими веб-сайтами и телефонными приложениями. Однако я думаю, что было бы разумно разработать API так, чтобы его можно было сделать общедоступным в будущем.

Аутентификация

Хотя я смотрел на OAuth, я думаю, что базовая аутентификация HTTP через SSL достаточно безопасна для нашего API. Из того, что я понимаю, HTTP Basic Authentication over SSL является полностью жизнеспособным способом аутентификации REST API. Это также довольно просто, что мне нравится, так как я новичок в разработке API.

Авторизация

Если пользователь входит в API, используя свое имя пользователя и пароль, ему будет предоставлен доступ только к определенным частям API. Это означает, что они будут иметь доступ к своему собственному контенту, но не к контенту других пользователей. Кроме того, они могут быть ограничены тем, что они все могут делать.

В дополнение к учетным записям пользователей я планирую также иметь другие (не пользовательские) учетные записи для более глобальных административных задач. Эти учетные записи потенциально могут иметь полный доступ к API.

Это хороший дизайн? ИЛИ плохо ли аутентифицировать пользователя таким образом? Должен ли я только аутентифицировать своих клиентов (т.е. приложения) таким образом?

Сессии

Мой большой вопрос: при входе пользователя в наше веб-приложение, как мне управлять его сеансами? REST предусматривает отправку имени пользователя и пароля с каждым запросом. Кроме того, REST API не имеет состояния, поэтому я не могу управлять сеансами там. Однако мне нужно отследить, что они каким-то образом вошли в веб-приложение. Они явно не могут войти вручную для каждого запроса.

Один из подходов заключается в том, что после входа пользователя в систему мы сохраняем его учетные данные (адрес электронной почты и пароль) в сеансе PHP. Затем каждый последующий запрос к API может использовать эти учетные данные. Однако сохранение имен пользователей и паролей в сеансе PHP кажется неправильным и очень небезопасным. Но если не сделать это таким образом, как люди управляют сеансами при взаимодействии с REST API?

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

Может ли кто-нибудь помочь с моими вопросами по дизайну?


php api rest session http-authentication
person Jonathan    schedule 25.07.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Аутентификация

HTTP Basic Auth через SSL довольно прост, это правда, но не так безопасен, как вы думаете. Вам нужно всего лишь установить 1 «поддельный» SSL-сертификат на клиенте, и с помощью атаки «человек посередине» вы сможете перехватить трафик.

Как установить поддельный сертификат? В браузере это не так сложно: многие пользователи просто нажимают «ОК», когда видят огромный красный экран с предупреждением. Например, на мобильном устройстве: http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/

С этим решением вам достаточно один раз перехватить трафик, и вы получите пароль пользователя!

Мой совет: сгенерируйте временный пароль при входе в систему и используйте его во всех остальных запросах. Таким образом, злоумышленник должен перехватить процесс входа в систему для пароля, и если вы храните этот пароль локально, например, на телефоне, это намного сложнее. (И, конечно же, вы можете добавить к нему истечение срока действия и т. Д.)

Авторизация

Я не очень понимаю, что бы вы сделали. Управление доступом пользователей — это хорошо, но это зависит от конкретного проекта.

Сеанс

Не только REST API, весь мир HTTP не имеет состояния. Если вы используете сеанс PHP, он сохраняет идентификатор сеанса в файле cookie на стороне клиента, и браузер каждый раз отправляет это значение файла cookie на сервер.

Пользователям не нужно каждый раз входить в систему. Они входят в систему один раз и получают токен / временный пароль и т. Д. И (или, если вы не используете эти вещи) они отправляют вам базовый заголовок аутентификации при каждом запросе. Таким образом, вы можете легко отследить, кто отправил вам запрос, потому что вы уже знаете, кто этот пользователь, и вы можете хранить и привязывать к нему некоторые данные на сервере.

Есть много способов работать с пользователями. Базовая авторизация — одна из них. И проверьте это: токены и сеансы OAuth в REST "токены OAuth явно являются идентификатор сеанса, ..."

Вам не нужно хранить пароль и адрес электронной почты пользователя, вам просто нужно проверять заголовки/файлы cookie/и т. д. от клиента в каждом запросе.

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

Могут, но сохранять настоящий пароль пользователя на телефоне — очень плохая практика. Сохранить жетон с ограниченным сроком действия немного лучше. :)

На всех других языках вы можете хранить значения, если хотите. Например, если вы хотите использовать клиент Python для своего API: он аутентифицирует и сохраняет токен или что-то, что ему нужно, в переменной, и при каждом другом запросе он использует эти сохраненные данные.

Еще одно примечание:

Однако сохранение имен пользователей и паролей в сеансе PHP кажется неправильным и очень небезопасным.

Правда, это небезопасно, но (настоящие) сеансы PHP хранятся на стороне сервера, и, как я уже сказал, он хранит только один идентификатор сеанса на стороне клиента. Любой, кто может получить этот идентификатор сеанса, может выдавать себя за данного пользователя. (Есть контрмеры, например, проверка IP и т. д.)

person Gerifield    schedule 21.08.2014