Тип авторизации REST API

1

Я много читал о том, как предоставить доступ к API REST, и я до сих пор не могу прийти к решению о том, что использовать.

В моем случае я пишу REST API, который будет использоваться пользователями мобильного приложения (android & iOS), поэтому я не предоставляю и не требую доступа от третьих лиц, и это заставляет меня думать, что мне не нужно использовать OAuth. Однако у меня есть соображения о том, как обеспечить доступ к одной учетной записи пользователя с нескольких устройств и как обеспечить автономный доступ.

Еще одно соображение, которое я имею, заключается в том, как ограничить доступ к API, например, если вы используете API Tokens, каковы наилучшие методы для истечения срока действия и обновления токенов?

Теги:
rest
jersey

2 ответа

1
Лучший ответ

В вашем вопросе есть несколько тем:

  • Каковы преимущества OAuth2 для внутреннего API, выставленного в Интернете?
  • Как мне управлять токенами?
  • Как пользователь может получить доступ через несколько устройств?
  • Как пользователь может иметь автономный доступ?

Я обсуждаю эти вопросы ниже.

oauth2

OAuth2 предлагает стандартизованный протокол для нескольких схем аутентификации различной сложности. Одним из наиболее сложных вариантов использования является поток "Authorization Code Grant", который позволяет владельцу ресурса (пользователю) предоставлять определенный доступ к клиентскому приложению через посредника, сервер авторизации. Это то, что происходит, когда вы входите в систему с помощью Google. Преимущество использования OAuth2 над решением доморощенного заключается в том, что протокол ясен для всех сторон и с меньшей вероятностью содержит фундаментальные недостатки. Недостатком может быть то, что протокол не настолько гибкий, поэтому некоторые пользовательские сценарии могут быть трудно поддерживать в пределах границ OAuth2. Если у вас нет необходимости в каком-либо типичном сценарии OAuth2 (или заинтересованной стороне, требующей использования OAuth2), то я предлагаю не начинать с нее, а сам реализовать простую схему токенов.

Управление жетонами

Наиболее распространенным способом управления доступом к API является использование токенов. Токен генерируется, когда пользователь входит в систему, как правило, с именем пользователя и паролем через HTTPS. Маркер сохраняется на сервере и должен быть предоставлен приложением в каждом запросе. Это похоже на идентификатор сеанса, используемый в веб-приложениях, который автоматически создается и обрабатывается в памяти контейнером приложения на сервере и передается через параметр cookie или request. Маркер API обычно обрабатывается уровнем безопасности самого приложения, сохраняется в базе данных и передается через заголовок "Авторизация".

У токена должна быть дата истечения срока действия. Нужно выбрать наилучший интервал для этого и обновить токен (каждый раз, когда пользователь обращается к API) или явно (заставить пользователя повторно вводить учетные данные после истечения срока действия). Это зависит от типа приложения и уровня требуемой безопасности. Токены также могут быть отменены вручную на сервере.

Несколько устройств

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

Автономный доступ

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

  • одно редактирование переопределяет другое в зависимости от типа редактирования или роли пользователя
  • последнее редактирование игнорируется или предлагается для разрешения последнему редактору
  • некоторые типы изменений могут быть "объединены" автоматически
  • и т.п.

Еще одна приятная и простая стратегия - запретить все изменения во время автономной работы.

Поделиться
  • 0
    Отличный ответ! Это проясняет все то, что мне было интересно, и приводит мои мысли в порядок. Поскольку я начал реализовывать REST API с токенами, это меня устраивает с некоторыми изменениями.
0

Есть две вещи, которые вы хотите защитить/аутентифицировать

  • Что клиентское приложение имеет право использовать эту услугу
  • Что пользователь имеет право доступа к персональным данным

Проверка подлинности приложения

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

Для аутентификации приложения все, что вы можете сделать - это иметь идентификатор клиента, но не секрет клиента. Например

http://service.com/rest?client_id=android

Reply method(String client_id) {
   if (!client_id in ["andoid", "ios"])
       return Unauthorized();
}

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

Проверка подлинности пользователя

Защита пользовательских данных имеет решающее значение и, к счастью, возможна. Главное различие заключается в том, что секрет не статически жестко закодирован в приложение, он известен только пользователю.

Один "простой" способ аутентификации пользователей - использовать другие учетные записи, которые у них есть. Схемы, подобные http://openid.net/connect/faq/, позволяют делать именно это.

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

http://service.com/rest?client_id=android&user_token=aasjkbn9nah9z23&user_auth_service=facebook

Reply method(String client_id, user_token, user_auth_service) {
   if (!client_id in ["andoid", "ios"])
       return Unauthorized();
   authenticated_user_id = user_auth_service.getUserIdOrFail(user_token);
   accessDatabase(authenticated_user_id);
}

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню