Аутентификация надежного веб-сервиса

У меня есть Restful API веб-сервисов, который используется разными третьими сторонами. Часть этого API ограничена (для этого вам нужно имя пользователя/пароль). Мне было интересно, какой был бы лучший способ аутентификации?

Я использую https, поэтому связь зашифрована. У меня есть две идеи:

Прежде чем пользователь начнет использовать (ограниченный) сервис, он отправит имя пользователя/пароль с помощью POST (поскольку https используется, учетные данные зашифровываются). После успешного входа в систему сервер отправляет обратно случайное одноразовое значение (nonce), которое соответствует этому имени пользователя. Когда выполняется следующий запрос, вдоль имени пользователя клиент отправляет ранее возвращенный nonce. Серверы сопоставляют имя пользователя и nonce и возвращают новые nonce вдоль запрашиваемых сторон. Каждый новый запрос использует новый nonce. В принципе, это облегченная версия аутентификации доступа к дайджесту.
Поскольку этот API используется от стороннего пользователя, имя пользователя/пароль может использоваться для каждого (ограниченного) запроса. Поскольку https используется, они будут зашифрованы. Падение этого подхода заключается в том, что это не будет удовлетворительным (POST будет использоваться всегда).

Я гораздо ближе выбираю первый подход (это легко реагировать на требования, относительно легко реализовать, XML, json или html можно использовать, не меняя ничего), но я хотел посмотреть, каково ваше мнение? Что вы рекомендуете: первый, второй или третий подход?

Btw, я использую Python на стороне сервера.

Ответ 1

Один из способов, с помощью которого я видел это в API (и том, как я его сейчас реализую), - создать ресурс RESTful с именем Session, созданный с помощью POST который предоставляет имя пользователя и пароль.

Вот в основном, как я его реализовал:

POST /sessions { Username: "User", Password: "Password" }

Создайте сеанс с ограничением по времени и верните ресурс сеанса, который содержит значение ключа сеанса и истечет. Вы также можете вернуть это как значение cookie для удобства реализации клиентов API.

DELETE /session/{id}

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

Затем я добавляю ключ сеанса через параметр запроса, хотя вы также можете разрешить его отправлять через значение cookie, я бы рекомендовал разрешить оба.

Я предпочитаю, чтобы это было очень просто.

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

Если вы используете HTTPS везде, вам, вероятно, не нужно слишком беспокоиться. Однако, если вы хотите использовать HTTP, вам нужно будет использовать что-то вроде хэша вместе с секретным ключом и произнести отметку времени для создания защищенного ключа для каждого запроса. Таким образом вы можете поделиться секретным ключом по HTTPS, а затем переключиться на HTTP для дальнейших вызовов. Даже если кому-то удастся вытащить ключ из запроса, он может истечь почти сразу и быть бесполезным.

Отказ от ответственности: я не эксперт по безопасности, -).

Ответ 2

Нет причин не просто использовать HTTP-аутентификацию здесь.

Тем не менее, концепция POSTing для получения временного блока nonce может работать хорошо. Но это мотивы относительно того, почему вам нужно было бы перепрыгнуть через этот дополнительный обруч в первую очередь.

Этот метод рассматривался при использовании хэша bcrypt для исходного пароля из-за фактического расхода на проверку пользователя (если вы не знаете, bcrypt может быть настроен на значительное время для выполнения хеш-функции). Был сделан выбор, чтобы предоставить услугу "войти в систему" один раз, используя пароль, который пройдет через дорогостоящий процесс проверки через bcrypt, и затем получит блокированный токен в обмен на будущие запросы, которые будут обходить процесс bcrypt.

В случае процесса bcrypt используйте HTTP-аутентификацию, служба будет работать как с обычным паролем, так и с токеном. Таким образом, пользователь всегда может использовать пароль для своего сервиса, но он просто становится дорогим. Поэтому они МОГУТ это сделать, им просто НЕ ДОЛЖНО. Службе не важно, какой метод аутентификации используется клиентом.

Служба nonce предлагается в качестве альтернативы для повышения пропускной способности.

Кроме этого, это стандартная HTTP-аутентификация, но с новой схемой.

Ответ 3

Amazon веб-сервисы это хорошо, проверьте методологию для некоторых идей. По сути, они заставляют клиентов шифровать специальный http-заголовок, используя свой пароль.

Здесь ссылка:

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

Ответ 4

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

GET /foo HTTP/1.1
Host: www.bar.com
X-MyUsername: foo
X-MyPassword: bar

Еще одна идея - использовать HTTP Basic Auth и просто отправить Authorization: Basic base64(user:password) -Header. То есть, если соединение всегда зашифровывается.