Я создаю дневник с картинками на веб-приложении google app engine, используя python. Пользователи могут зарегистрироваться и опубликовать фотографии в своем дневнике.

Кроме того, я стараюсь максимально соответствовать архитектуре REST ведения дел.

Схема аутентификации основана на этом для веб-приложения:
1. Отправьте имя пользователя / пароль от веб-интерфейса
2. Backend устанавливает cookie в случае успешной аутентификации
3. Остальные сделанные AJAX-вызовы аутентифицируются с помощью этого файла cookie.

Есть ли способ соответствовать REST без использования файлов cookie?

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

Схема аутентификации для Android-клиента:
ВАРИАНТ А
1. Отправьте имя пользователя / пароль через https на веб-сервис
2. Веб-сервис возвращает уникальный токен авторизации (сохраните токен в таблице username / pwd в хранилище данных)
3. Запросите последующие услуги, добавив этот токен в заголовок запроса.
4. Сервер сопоставляет токен с таблицей username / pwd и возвращает данные, если токен найден
5. Срок действия токена авторизации истекает через определенный промежуток времени

ВАРИАНТ b
1. Установите секретный ключ на стороне клиента и сервера
2. Используйте «username: hash of password and secret key» в заголовке авторизации каждого запроса
3. сервер генерирует пароль путем извлечения пароля из значения хеш-функции, используя тот же алгоритм хеширования; в случае успеха возвращает данные
Кстати, я не хотел использовать базовую авторизацию из-за ее уязвимостей в безопасности.

Что лучше ?

Существуют ли другие значительно лучшие способы для достижения того, что я пытаюсь сделать? Между прочим, безопасность меня беспокоит.
Буду признателен, если у кого-нибудь есть понимание этого вопроса. Благодарю.

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

Шаги теперь будут:
1. Сгенерируйте подпись, используя oauth_parameters (consumer_key, signature_method, timestamp), URL-адрес запроса, параметры запроса и SECRET.
2. Включите подпись, параметры oauth при оформлении запроса.
3. Сервер проверяет запрос, снова генерируя подпись, за исключением того, что в этом случае он использует СЕКРЕТ, соответствующий ключу

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

Какие плюсы / минусы в том, чтобы так поступать?