Аутентификация при отделении API от веб-приложения

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

Вот некоторый упрощенный код для иллюстрации того, как все работает в данный момент:

// GET https://foo.example.com/module/trips.php
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
require 'views/trips.php';
}

// POST https://foo.example.com/module/trips.php?action=take
// ...
// this request can come from AJAX, for example
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
$model->assignTrip($SESSION->operatorID, $_POST['trip_id']);
}

Очевидно, что это не очень RESTful, следовательно, усилия, чтобы разделить два. Это то, что я предложил (все еще в стадии разработки):

// GET https://api.foo.example.com/v1.0/trips
echo json_encode($model->getAllTrips());

// POST https://api.foo.example.com/v1.0/trips/:trip_id/operator
$model->assignTrip($_POST['operator_id'], $trip_id);

Я понимаю, что REST без гражданства. В этом упрощенном примере только оператор должен иметь возможность назначить себе поездку. Как мне применить это с помощью API?

Я прочитал много-много вопросов и статей об аутентификации с помощью API REST, и все они говорят об OAuth / OAuth2, который, кажется, отлично подходит для аутентификации клиентов API с помощью токенов, но ничего об аутентификации пользователей API-клиента (или, возможно, я неправильно понимаю что-то?) В моем случае мой клиент API все еще является веб-приложением.

Мой главный вопрос: Как API должен определять, кто пользователь? Или это вообще должно быть?

В качестве альтернативы я решил сделать это в веб-приложении:

// POST https://foo.example.com/module/trips.php?action=take
// ...
// this request can come from AJAX, for example
if (isLoggedIn() && isAuthorized($SESSION->operatorID)) {
// Use cURL to send an HTTP POST request with the appropriate data to
// https://api.foo.example.com/v1.0/trips/6/operator
}

Это кажется ненужным, но вот как это выглядит в этом ответе. Я думал, что после моей реструктуризации я должен делать что-то вроде этого из JavaScript:

$.ajax({
type: 'POST',
url: 'https://api.foo.example.com/v1.0/trips/' + trip + '/operator',
data: {
operator_id: 6601
}
}).success(function() {
// It worked!
});

Я смотрел на GitHub API Authentication в качестве примера и использует базовое использование curl -u "username" <api-endpoint-url>, Я не обеспокоен использованием Authorization Заголовок HTTP, так как это приложение уже только HTTPS, но в этом случае мне не нужно хранить пароль локально (например, веб-хранилище или что-то еще)?

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

Возможно, я неправильно понимаю, как API должны работать в целом, если так, то было бы здорово, если бы кто-то это прояснил!

1

Решение

Я согласен, что отправлять некоторые данные заголовка и хранить их локально странно, но, поверьте, это так.

Вы можете взглянуть на Аутентификация HMAC.

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

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

Очистить все:

  1. Сделайте вызов API для аутентификации пользователя
  2. Сервер проверит логин / пароль пользователя, если все нормально, он сохранит токен и вернет его по запросу.
  3. Клиент хранит токен
  4. Все последующие запросы будут отправлять этот токен в заголовке
  5. Сервер всегда проверяет, является ли этот токен действительным, и находит текущего пользователя, используя токен или другие данные, отправленные в заголовках.
0

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector