Самый простой метод - требовать, чтобы все коммуникации проходили по HTTPS (чтобы данные были конфиденциальными; никто, кроме клиента и сервера их не видел), и использовал простое имя пользователя и пароль при каждом запросе внутри этого защищенного соединения. Это очень просто сделать на практике (имя пользователя и пароль фактически передаются по соединению в виде HTTP-заголовка, что здесь нормально, потому что мы используем HTTPS), и сервер может проверять каждый раз , что пользователь позволено. Вам не нужно беспокоиться о рукопожатиях SSL; Это ответственность уровня SSL / HTTPS (и именно поэтому HTTPS / SSL хороший ).
В качестве альтернативы, вход в систему может быть выполнен любым методом и генерировать некое магическое число (например, UUID или криптографический хэш случайного числа и имени пользователя), которое хранится в файле cookie сеанса. Последующие запросы могут просто проверить, является ли магический номер тем, который он распознает с начала сеанса (и что с момента его выдачи прошло не так много времени); Выход из системы просто забывает о магическом числе на стороне сервера (и просит клиента забыть тоже). Это немного сложнее для реализации этого, но все еще не сложно, и есть серверные библиотеки для обработки осла.
Первый вариант особенно хорош для случаев, когда вы пишете что-то, что будет использоваться другими программами, поскольку его действительно легко реализовать. Второй вариант лучше, когда клиент является веб-браузером, так как он дает пользователям больший контроль над тем, когда их браузер авторизован (программные API не склонны к таким вещам). Когда клиент будет браузером, вам нужно позаботиться о защите от других типов атак (например, различных типов подделки запросов), но это в значительной степени не зависит от всего остального.