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

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

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

Возможные опции

POST для чего-то вроде https://api...com/v1/login.json
A PUT для чего-то вроде https://api...com/v1/users.json
Что-то у меня не было...

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

Ответ 1

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

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

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

1st: it устраняет необходимость в том, чтобы соединители сохраняли состояние приложения между запросами, что уменьшает потребление физических ресурсов и улучшение масштабируемости;
3rd: позволяет посреднику просматривать и понимать запрос изолированно, которые могут потребоваться, когда услуги динамически перестраиваются;

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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