Шаблон входа REST API

Я создаю REST API, внимательно следуя советам Apigee, используя существительные, а не глаголы, версию API, запеченную в URL, два пути API для каждой коллекции, использование GET POST PUT DELETE и т. Д.

Я работаю над системой входа в систему, но не уверен в правильном способе REST для входа пользователей. Я не работаю над безопасностью на данный момент, просто шаблон входа или поток. (Позже мы будем добавлять 2 шага oAuth с HMAC и т. Д.)

Возможные варианты

• ПОЧТА что-то вроде https://api...com/v1/login.json
• Положить на что-то вроде https://api...com/v1/users.json
• Что-то у меня нет, хотя ...

Каков правильный стиль REST для входа в систему пользователей?

Принципиальное проектирование современной веб-архитектуры Роя Т. Филдинга и Ричарда Н. Тейлора , т. Е. Последовательность работ из всей терминологии REST, содержит определение взаимодействия клиент-сервер:

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

Это ограничение выполняет четыре функции, 1-я и 3-я важны в данном конкретном случае:

• 1-й : устраняет необходимость в соединителях для сохранения состояния приложения между запросами , что снижает потребление физических ресурсов и повышает масштабируемость;
• 3-й : он позволяет посреднику просматривать и понимать запрос изолированно , что может быть необходимо при динамической реорганизации сервисов;

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

Одним из примеров того, как это можно заархивировать, является код аутентификации сообщений на основе хэша или HMAC . На практике это означает добавление хеш-кода текущего сообщения к каждому запросу. Хеш-код, рассчитанный с помощью криптографической хеш-функции в сочетании с секретным криптографическим ключом . Криптографическая хеш-функция либо предопределена, либо является частью концепции REST кода по требованию (например, JavaScript). Секретный криптографический ключ должен быть предоставлен сервером клиенту в качестве ресурса, и клиент использует его для вычисления хеш-кода для каждого запроса.

Есть много примеров реализации HMAC , но я бы хотел, чтобы вы обратили внимание на следующие три:

• Аутентификация REST-запросов для Amazon Simple Storage Service (Amazon S3)
• Ответ Mauriceless на вопрос: «Как реализовать аутентификацию HMAC в API RESTful WCF»
• crypto-js: реализации JavaScript стандартных и безопасных криптографических алгоритмов

Как это работает на практике

Если клиент знает секретный ключ, он готов работать с ресурсами. В противном случае он будет временно перенаправлен (код состояния 307 Temporary Redirect) для авторизации и получения секретного ключа, а затем перенаправлен обратно на исходный ресурс. В этом случае нет необходимости заранее знать (т. Е. Где-то жестко), какой URL-адрес для авторизации клиента , и можно со временем изменить эту схему.

Надеюсь, что это поможет вам найти правильное решение!

TL; DR Логин для каждого запроса не является обязательным компонентом для реализации безопасности API, аутентификация есть.

Трудно ответить на ваш вопрос о входе в систему, не говоря о безопасности в целом. С некоторыми схемами аутентификации нет традиционного входа в систему.

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

1. Пользователь утверждает клиент API и разрешает делать запросы в виде долгоживущего токена
2. Клиент Api получает недолговечный токен, используя долгоживущий.
3. Api клиент отправляет недолговечный токен с каждым запросом.

Эта схема дает пользователю возможность аннулировать доступ в любое время. Практически все общедоступные API RESTful, которые я видел, используют OAuth для реализации этого.

Я просто не думаю, что вы должны формулировать свою проблему (и вопрос) с точки зрения входа в систему, а скорее думать о защите API в целом.

Для получения дополнительной информации об аутентификации REST API в целом вы можете обратиться к следующим ресурсам:

• http://www.infoq.com/news/2010/01/rest-api-authentication-schemes
• Аутентификация REST API
• RESTful API-аутентификация

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

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

Но для REST API экран входа в систему и сеансовые куки не являются строго необходимыми, поскольку каждый запрос может включать учетные данные, не влияя на пользователя; и если клиент не сотрудничает в любое время, 401может быть дан «несанкционированный» ответ. RFC 2617 описывает поддержку аутентификации в HTTP.

TLS (HTTPS) также может быть опцией, и он позволит аутентифицировать клиента на сервере (и наоборот) при каждом запросе путем проверки открытого ключа другой стороны. Кроме того, это обеспечивает канал для бонуса. Конечно, обмен парой ключей перед связью необходим для этого. (Обратите внимание, что речь идет именно об идентификации / аутентификации пользователя с помощью TLS. Защита канала с помощью TLS / Diffie-Hellman всегда хорошая идея, даже если вы не идентифицируете пользователя по его открытому ключу.)

Пример: предположим, что токен OAuth - это ваши полные учетные данные для входа. Если у клиента есть токен OAuth, он может быть предоставлен в качестве идентификатора пользователя в стандартной HTTP-аутентификации для каждого запроса. Сервер может проверить токен при первом использовании и кэшировать результат проверки с указанием времени жизни, которое обновляется при каждом запросе. Любой запрос, требующий аутентификации, возвращается, 401если не предоставлен.