Мобильное приложение обращается к API – вопрос аутентификации

  • Автор темы antosha1
  • 44
  • Обновлено
  • 13, May 2024
  • #1
ПРИВЕТ,

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

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

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

Всякий раз, когда приложение выполняет вызов API, ключ добавляется в заголовок.

Прежде чем API что-либо сделает, он проверяет ключ и проверяет его действительность.

Только после проверки выполняется остальная часть вызова API. Токены хранятся на стороне API в базе данных вместе с датой истечения срока действия и пользовательским агентом.

Если пользовательский агент отличается от того, который использовался для создания токена, токен немедленно становится недействительным и удаляется. Это относительно безопасный метод или есть ли какие-либо риски для безопасности? Спасибо

antosha1


Рег
25 Jan, 2013

Тем
1

Постов
5

Баллов
15
  • 20, May 2024
  • #2
Вы возвращаете токен, а не ключ.

Ключ — это нечто постоянное, специфичное для приложения или разработчика.

Токены генерируются «на лету», для конкретной сессии, на определенное время.

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

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

Это то, что вы возвращаете: ТОКЕН, а не КЛЮЧ.

Ключ полностью отсутствует в вашем потоковом процессе.

Теперь всякий раз, когда приложение делает запрос, оно отправляет на ваш сервер как свой КЛЮЧ разработчика, так и ТОКЕН в заголовках.

Ваш сервер проверяет, действителен ли КЛЮЧ и действителен ли ТОКЕН, и обрабатывает запрос, регистрируя КЛЮЧ и запрошенное действие.

Имея только токен и без KEY, невозможно узнать, какое приложение разработчика отправило запрос.

Предположим, 5 человек создали 5 приложений, используя ваш API.

Каждое приложение отправляет пользователя на ваш сайт для аутентификации.

Пользователь вводит свой адрес электронной почты/пароль для входа.

Вы вернули токен в приложение.

Можете ли вы сказать, какое из 5 приложений делает запрос? Нет.

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

Если вы единственный, кто может создать приложение, API не является общедоступным, даже в этом случае используйте проверку КЛЮЧА разработчика вместо проверки пользовательского агента.

Если кто-то украдет токен, он не сможет украсть ключ разработчика, поскольку он жестко запрограммирован в вашем приложении.

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

Но ключ разработчика всегда остается в заголовках и никогда не отображается.

Проверка пользовательского агента бесполезна.

Подделать пользовательский агент так просто... Надеюсь, я правильно понял ваш вопрос.
 

apachexxx


Рег
29 Oct, 2014

Тем
0

Постов
2

Баллов
2
  • 09, Jun 2024
  • #3
Спасибо за объяснение.

Просто поясним: API не будет общедоступным, и, насколько запланировано, будет создано только одно приложение с использованием этого API.

Хотя пользовательский агент легко подделать, для проверки токена вам необходимо знать, что вам также нужен точный пользовательский агент.

Если у вас есть только токен, это бесполезно.

Также можно вернуть токен API через заголовок.

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

Владимир Ильин1


Рег
26 May, 2014

Тем
1

Постов
3

Баллов
13
Тем
49554
Комментарии
57426
Опыт
552966

Интересно