2013-07-22 6 views
13

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

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

Basic аутентификации через HTTPS - Проверьте имя пользователя/пароль пользователя для каждого запроса.

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

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

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

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

ответ

16

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

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

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

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

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

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

+0

Не могли бы вы подробно остановиться на «Идентификатор сеанса не является формой аутентификации, а скорее результатом авторизации»? – paul

+0

Обновлен мой ответ, вкратце - Идентификатор сеанса не является формой аутентификации, маркер API. –

+0

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