Проверка подлинности API REST для веб-приложения и мобильного приложения

У меня возникли проблемы с решением, как реализовать аутентификацию для RESTful API, который будет безопасен для использования как веб-приложением, так и мобильным приложением.

Во-первых, я подумал исследовать базовую аутентификацию HTTP через HTTPS в качестве опции. Это будет хорошо работать для мобильного приложения, где имя пользователя и пароль могут храниться в цепочке ключей ОС надежно и не могут быть перехвачены при передаче, поскольку запрос будет передаваться по HTTPS. Это также элегантно для API, так как оно будет полностью без сохранения состояния. Проблема с этим для веб-приложения. Не будет доступа к такой цепочке для ключей для хранения имени пользователя и пароля, поэтому мне нужно будет использовать cookie или localStorage, но тогда я храню личные данные пользователя в легкодоступном месте.

После дополнительных исследований я нашел много разговоров об аутентификации HMAC. Проблема, с которой я сталкиваюсь при таком подходе, заключается в том, что должен быть общий секрет, который знают только клиент и сервер. Как я могу получить этот секрет для каждого пользователя в веб-приложении, если у меня нет конечной точки api/login, которая берет имя пользователя/пароль и возвращает секрет для сохранения в файле cookie? использовать в будущих запросах. Это представляет состояние API, однако.

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

Я действительно не хочу реализовывать OAuth. Это, вероятно, излишне для моих нужд.

Мне кажется, что я не совсем понимаю HMAC, поэтому я хотел бы получить объяснение и узнать, как можно безопасно реализовать его с помощью веб-приложения и мобильного приложения.

Обновить

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

Ответ 1

Вы должны использовать OAuth2. Вот как:

1) Мобильное приложение

Учетные данные клиента мобильного приложения хранятся, как вы сами заявляете. Затем он использует "Credentials Credentials Credentials" (см. http://tools.ietf.org/html/rfc6749#section-4.3) для отправки этих учетных данных. В свою очередь, он получает токен (несущий), который может использовать в следующих запросах.

2) Веб-сайт

Веб-сайт использует "Предоставление кода авторизации" (см. http://tools.ietf.org/html/rfc6749#section-4.1):

Веб-сайт видит несанкционированный запрос и перенаправляет браузер на конечную точку авторинга с поддержкой HTML в REST api.
Пользователь аутентифицируется с помощью службы REST
Сайт REST перенаправляет пользователя на сайт с маркером доступа в URL-адресе.
Сайт вызывает сайт REST и заменяет токен доступа на токен авторизации.

Здесь, после того как веб-сайт использует токен авторизации для доступа к службе REST (от имени конечного пользователя) - обычно путем включения токена в качестве токена "проводника" в заголовке HTTP-авторизации.

Это не ракетостроение, но для полного понимания требуется некоторое время.

3) Ограничение доступа API для определенных приложений

В OAuth2 каждому клиенту выдается идентификатор клиента и секрет клиента (здесь "клиент" - ваше мобильное приложение или веб-сайт). Клиент должен отправить эти учетные данные при авторизации. Ваша служба REST может использовать это для проверки вызывающего клиента

Ответ 2

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

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

Ответ 3

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

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

Авторизация кодируется в API с использованием списка управления доступом и пользовательских разрешений и настроек, которые настраиваются в коде API, конфигурации и базе данных по мере необходимости. Простая инструкция if в API может протестировать авторизацию и вернуть соответствующий ответ (не авторизованный или результаты обработки вызова API).

Теперь проверка подлинности проверяется, является ли вызов подлинным. Для этого я выдаю самоподписанные сертификаты клиентам. Вызов API осуществляется с их сервера всякий раз, когда они хотят - обычно, когда они генерируют свою первую страницу (или когда они выполняют свои собственные проверки входа в приложение). Этот вызов использует ранее предоставленные сертификаты. Если на моей стороне я рад, что сертификат действителен, я могу вернуть ключ nonce и время, сгенерированное с помощью ключа. Этот ключ используется во всех последующих вызовах для других конечных точек API, например, в заголовке канала, и его можно хранить достаточно открыто в поле формы HTML или переменной javascript или переменной в приложении.

Функция nonce предотвратит повторные атаки и ключ API может быть украден, если кто-то захочет - они не смогут продолжать использовать по истечении срока действия или если изменения nonce до того, как они совершают следующий вызов.

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

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

Ответ 4

Может быть, это поможет: https://sintoth.com/api, вот пример:

<?php
require_once("sintothauthentication.php");
if(!user_logged_in("[email protected]", "MY_API_KEY")) {
$login_data = login("[email protected]", "password", "MY_API_KEY");

if(@$login_data[1] == 1 && $login_data[0] != "361") {
    echo "Hello, " . $login_data[2];
} else {
    echo "Please check the login data.";
}                              
}
?>

Чтобы пример работал, вам нужно скачать инструментарий с Github: https://github.com/sintoth/sintothaccounts-api/blob/master/sintothaccounts-api-toolkit.php

Вы получаете API-ключ от sintoth.com/apiconsole и учетной записи sintoth: https://sintoth.com/login/register