Правильный способ управления auth через REST api?

Question

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

У меня есть общее веб-приложение, и я хочу создать универсальное мобильное приложение, чтобы пойти с ним. Для того, чтобы пользователи могли сохранять данные/доступ к конкретным данным пользователя/etc, они должны войти в систему, и логин должен быть аутентифицирован через REST api веб-приложения.

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

Для входа в систему пользователь вводит свое имя пользователя и пароль, которые затем отправляются как строки запроса в соответствии с методом выше. Запрос проверяется на достоверность на другом конце, а пара имени пользователя и пароля проверяется на базе данных. Если логин верен, для этого пользователя и открытого ключа генерируется случайный «токен аутентификации» и отправляется обратно в мобильное приложение для хранения локально на устройстве.

Когда следующий запрос поступает из мобильного приложения, одной из переменных строки запроса является «токен авторизации» ранее, который проверен на достоверность (с открытым ключом приложения) против таблицы «auth tokens» в базе данных , Если он действителен, выполните запрос.

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

Есть ли какие-либо другие шаги или вещи, которые я пропустил, что было бы полезно? Например, я читал, что также должна быть переменная timestamp, которая должна быть проверена на временной интервал 5/10min в запросе. Любые временные метки старше 5/10 минут и запрос должны быть отклонены. Это важно?

спасибо.

Answer 1

Что вы описываете, это в основном домашняя версия 2-legged OAuth. Существует множество реализаций, которые вы можете использовать в основном. Всякий раз, когда дело доходит до вещей, связанных с безопасностью, я прохожу мимо: если другие уже это сделали, не изобретайте велосипед. OAuath используется многими крупными сайтами (Twitter, Facebook, GitHub, Google, ...), и они провели много исследований, которые вошли в стандарты OAuth. Поэтому я бы предложил использовать их.

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