Как я могу реализовать аутентификацию спокойным способом?

Question

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

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

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

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

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

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

ОПЦИЯ b
1. Установите секретный ключ на стороне клиента и сервера
2. Используйте «имя пользователя: хэш пароля и секретный ключ» в заголовке авторизации каждого запроса
3. Сервер генерирует пароль, извлекая парольиз значения хеша с использованием того же алгоритма хеширования;в случае успешного возврата данных
кстати, я не хотел использовать базовую авторизацию из-за ее уязвимостей в безопасности.

Что лучше?

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

---

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

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

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

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

Answer 1

Если «безопасность - это проблема», то я бы сказал, что вам было бы намного лучше, если бы вы использовали открытые стандарты и библиотеку для достижения того, чего вы хотите.Основная причина этого заключается в том, что если вы делаете это сами, вы, скорее всего, что-то забудете;У этих стандартов было много глаз, смотрящих на них, ищущих дыры.

Ваши варианты включают (с повышением уровня сложности)

Базовая аутентификация и HTTPS

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

Дайджест-аутентификация

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

OAuth

Посмотрите, как Google предоставляет OAuth для установленных приложений.Я считаю, что это не то, что вы ищете, так как вы не просите обмениваться данными между приложениями, а просто аутентифицировать пользователей.

Сверните свои собственные

Если вы хотите свернуть своиЯ предлагаю посмотреть, например, как Google (сейчас устарел?) ClientLogin используется для работы.

1. Клиенты получат защищенный ресурс и получат 401 с инструкциями для выполненияАутентификация GoogleLogin, включая URI для того, где выполнить саму регистрацию
2. Клиенты (зная, как это сделать) POST запрос определенным образом на этот URI
3. Сервер отвечает определенным ответомвключая (длинный) токен
4. Теперь клиент может выполнять запросы GET к защищенному ресурсу с этим токеном.

Безгражданство

Вы цитируете REST, который требует, чтобызапросы не должны конкретно зависеть от предшествующего взаимодействия: «... каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запросаst, и не может использовать любой сохраненный контекст на сервере. "( fielding ) Это означает, что сервер не должен хранить разговорный контекст (например, токен аутентификации) в таблице.

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

Редактировать: Хотя я не уверен,маловероятно, что у Google есть таблица всех выданных токенов аутентификации;Длина их токенов предполагает, что токен является неким зашифрованным сообщением, доказывающим, что тот, кто держит этот токен, действительно предоставлял реальные учетные данные в некоторой области в некоторый момент времени.

Answer 2

OAuth делает именно то, что вы хотите сделать стандартным способом.

Answer 3

Вы можете использовать комбинацию HTTPS и HTTP Basic Auth. Оба являются существующими стандартами и должны быть достаточно безопасными при совместном использовании.