Делаем аутентификацию в REST API – Уголок системного программиста

One of the major points of REST as a concept is to avoid the use of session state so that it’s easier to scale the resources of your REST endpoint horizontally. If you plan on using PHP’s $_SESSION as outlined in your question you’re going to find yourself in a difficult position of having to implement shared session storage in the case you want to scale out.

While OAuth would be the preferred method for what you want to do, a full implementation can be more work than you’d like to put in. However, you can carve out something of a half-measure, and still remain session-less. You’ve probably even seen similar solutions before.

1. When an API account is provisioned generate 2 random values: a Token and a Secret.
2. When a client makes a request they provide:
   • The Token, in plaintext.
   • A value computed from a unique, but known value, and the Secret. eg: an HMAC or a cryptographic signature
3. The REST endpoint can then maintain a simple, centralized key-value store of Tokens and Secrets, and validate requests by computing the value.

In this way you maintain the “sessionless” REST ideal, and also you never actually transmit the Secret during any part of the exchange.

Client Example:

$token  = "Bmn0c8rQDJoGTibk";                 // base64_encode(random_bytes(12));
$secret = "yXWczx0LwgKInpMFfgh0gCYCA8EKbOnw"; // base64_encode(random_bytes(24));
$stamp  = "2022-10-12T23:54:50 00:00";        // date("c");
$sig    = hash_hmac('SHA256', $stamp, base64_decode($secret));
// Result: "1f3ff7b1165b36a18dd9d4c32a733b15c22f63f34283df7bd7de65a690cc6f21"

$request->addHeader("X-Auth-Token: $token");
$request->addHeader("X-Auth-Signature: $sig");
$request->addHeader("X-Auth-Timestamp: $stamp");

Server Example:

$token  = $request->getToken();
$secret = $auth->getSecret($token);
$sig    = $request->getSignature();

$success = $auth->validateSignature($sig, $secret);

It’s worth noting that if decide to use a timestamp as a nonce you should only accept timestamps generated within the last few minutes to prevent against replay attacks. Most other authentication schemes will include additional components in the signed data such as the resource path, subsets of header data, etc to further lock down the signature to only apply to a single request.

When this answer was originally written in 2022 JWTs were quite new, [and I hadn’t heard of them] but as of 2020 they’ve solidly established their usefulness. Below is an example of a manual implementation to illustrate their simplicity, but there are squillions of libs out there that will do the encoding/decoding/validation for you, probably already baked into your framework of choice.

function base64url_encode($data) {
  $b64 = base64_encode($data);
  if ($b64 === false) {
    return false;
  }
  $url = strtr($b64, ' /', '-_');
  return rtrim($url, '=');
}

$token  = "Bmn0c8rQDJoGTibk";                 // base64_encode(random_bytes(12));
$secret = "yXWczx0LwgKInpMFfgh0gCYCA8EKbOnw"; // base64_encode(random_bytes(24));

// RFC-defined structure
$header = [
    "alg" => "HS256",
    "typ" => "JWT"
];

// whatever you want
$payload = [
    "token" => $token,
    "stamp" => "2020-01-02T22:00:00 00:00"    // date("c")
];

$jwt = sprintf(
    "%s.%s",
    base64url_encode(json_encode($header)),
    base64url_encode(json_encode($payload))
);

$jwt = sprintf(
    "%s.%s",
    $jwt,
    base64url_encode(hash_hmac('SHA256', $jwt, base64_decode($secret), true))
);

var_dump($jwt);

Yields:

string(167) "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbiI6IkJtbjBjOHJRREpvR1RpYmsiLCJzdGFtcCI6IjIwMjAtMDEtMDJUMjI6MDA6MDArMDA6MDAifQ.8kvuFR5xgvaTlOAzsshymHsJ9eRBVe-RE5qk1an_M_w"

and can be validated by anyone that adheres to the standard, which is pretty popular atm.

Anyhow, most APIs tack them into the headers as:

$request->addHeader("Authorization: Bearer $jwt");

@IOleg, теперь вопрос куда яснее. Я так понимаю, вы создаете API, в этом случае сессии нельзя использовать – привязка клиент-сессия осуществляется через куки, ее можно имитировать через курл, но никто так не делает, слишком мног омороки с инвалидацией. Обычно создается секретный ключ, который знают только сервис и клиент; после этого с помощью секретного ключа создается подпись к каждому запросу, которая позволяет установить, что запрос

1. Действительно был послан тем клиентом, который указан в запросе
2. Все параметры запросы действительно прописаны оригинальным клиентом (запрос может быть перехвачен по пути, после чего в него можно напихать “своих” параметров, если этой проверки не будет)
3. Запрос действительно отправлен клиентом только что, а не какой-то плохой MITM взял и заново послал запрос, который уже проходил месяц назад.

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

1. Сервер и клиент обмениваются секретным значением. Делается это единожды и не по тому каналу связи, по которому потом будут идти запросы, обычно он выдается в неавтоматическом режиме в админке сервиса разработчику клиента.
2. Клиент формирует полный запрос, причем не конкретные объекты, представляющие HTTP-запрос, а именно набор параметров – URL, список аргументов, время запроса, необходимые ключи (В данном случае – один секретный), свой айдишник у сервера, nonce или время отправки запроса (в этом случае время запроса добавляется обычным аргументом; ниже – подробнее)
3. Клиент сериализует все данные и получает из них хэш и включает аргументом в запрос. Хэш зависит от секретного ключа, времени запроса/nonce и всех параметров запроса – в результате злоумышленник должен знать весь этот набор для создания имитирующего запроса, а с учетом использования времени запроса или nonce он не может просто взять и повторить запрос.
4. Сервер получает запрос, разбивает на аргументы, составляет точно такой же хэш и убеждается в корректности/некорректности запроса. Если запрос корректен, то он выполняется и обратно отправляется ответ.

Таким образом, явной авторизации (авторизовался и забыл) нет – подписывается каждый запрос, а “пароль” не передается никогда.

Что там с датой и nonce: есть уже упомянутый вид атак, называемых replay attack. Допустим, клиент запросил сервер поменять имя какого-нибудь проекта на “аааа”, а затем еще раз – на “ббб”. Подслушивающая Ева в этом случае может повторить запрос смены имени на “аааа” то количество раз, которое ей покажется достаточным, чтобы насолить серверу и клиенту. Против этого есть два способа борьбы:

1. Клиент включает в запрос (и хэш) время отправки запроса. Сервер проверяет время прихода запроса, и, если время вышло за пределы позволенного временного отрезка (скажем, пяти минут), то сервер инвалидирует запрос и отказывается его выполнять. Подменять в запросе время отправки бессмысленно, т.к. в этом случае не сойдется хэш, и сервер инвалидирует запрос уже на этапе проверки хэша.
2. Сервер выдает клиентам nonce – number used once. В этом случае сервер выдает и запоминает уникальные одноразовые значения для подписи запрослв (те же хэши, например) своим клиентам, после чего, когда приходит запрос, он проверяет наличие такого nonce в своем репозитарии, и если его нет, инвалидирует запрос, а если есть, то этот nonce удаляется из репозитария, и Ева опять не может ни повторить запрос, ни использовать уже использованный nonce. Сервер при этом может не просто хранить nonce, но и запоминать привязку по айпи и дате (хотя на самом деле подменить айпи пакета не составляет особого труда, только вот ответ в этом случае уйдет не тому, кто подменил).

nonce чаще всего используется в том случае, когда клиент – это браузер пользвателя и там сложно говорить об api в классическом смысле; в частности, csrf-token – это nonce, обычно сгененрированный на основе ip пользователя.