Что такое токен API

Я пытаюсь разработать лучший способ обработки аутентификации пользователей для моего мобильного приложения (iOS и Android) и API (PHP).

Из того, что я исследовал, есть следующие варианты:

Basic auth over HTTPS - Проверьте имя пользователя/пароль пользователя для каждого запроса.

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

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

Я предполагаю, что мое объяснение токенов API неверно, поскольку они кажутся идентичными сеансам, потому что я храню идентификатор сеанса в БД.

  1. Мое объяснение токенов API будет исправлено. Для чего они? Как они отличаются от идентификаторов сеансов?
  2. В чем преимущества API-токенов?
  3. Является ли oAuth (если мы хотим упростить его использование) только протокол для создания "токенов API"?

ОТВЕТЫ

Ответ 1

Я не эксперт, но я дам вам пару центов, которые я взял:

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

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

2) Анекдоты API заменяют отправку некоторой комбинации имени пользователя и пароля по HTTP, которая небезопасна. Однако проблема все еще существует, что кто-то может использовать и использовать токен API.

3) В некотором смысле да. Это метод для сохранения токенов API "свежий". Вместо того, чтобы проходить вокруг одного и того же маркера API, вы запрашиваете токен доступа, если хотите использовать службу. Шаги OAuth 2.0 следующие:
a) Запрос, отправленный на службу с определенными полномочиями
b) Успешный ответ возвращает код
c) Другой запрос на обслуживание выполняется с кодом
d) Успешный ответ возвращает токен доступа для подписания каждого запроса API с этого момента до конца.

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