OAuth 1.0 по сравнению с OAuth 2.0

Введение в OAuth

Давайте рассмотрим OAuth в качестве служебного ключа автомобиля. В отличие от обычного ключа, который дает владельцу неограниченный доступ, камердинер использует этот ключ только для временной поездки без доступа к бардачку или багажнику. OAuth позволяет использовать данные учетной записи конечного пользователя сторонними службами, такими как Amazon, Facebook, Google, Instagram, LinkedIn, Netflix, Paypal, Microsoft, Twitter и т. д. Эти компании работают со многими сторонними приложениями и часто разрешают пользователям делиться своими учетными данными в приложениях, таких как новостные веб-сайты, блог-платформы, онлайн-видеоигры и т. д.

Например, при входе в другое приложение на Facebook пользователь может нажать кнопку входа в Facebook. Затем Facebook автоматически аутентифицирует их, и веб-сайт предоставляет им доступ с разрешения Facebook. OAuth также используется для проверки подлинности электронной почты, например Gmail, в которой веб-служба получает доступ к защищенным ресурсам на другом устройстве, позволяя пользователю получить доступ к двум разным службам с одним входом в систему.

OAuth-версия:

OAuth 2.0 — это полностью переписанная структура OAuth 1.0, а версия 1.0 считается протоколом, использующим другую терминологию и термины. Основное различие в функциях заключается в том, как обе версии классифицируют обязанности и взаимодействие с конечным пользователем.

В OAuth 1.0 есть потребитель, поставщик услуг и пользователь, и он не разделяет явно роли сервера ресурсов и сервера авторизации.

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

ОАут 1.0

⇒ пользователь A хочет, чтобы приложение 1 имело доступ к данным в приложении 2.

⇒ Приложение 1 отправляет запрос на соединение с Приложением 2, инициированный пользователем А.

⇒ Приложение 2 принимает запрос от Приложения 1.

⇒ Приложение 2 отправляет временный токен в Приложение 1.

⇒ Приложение 1 перенаправляет пользователя A для входа в систему или предварительно отформатированные URL-адреса.

⇒ После того, как пользователь А успешно аутентифицируется в Приложении 1, Приложение 1 запрашивает у пользователя А разрешение на предоставление приложению 2 разрешения на доступ к ресурсам Приложения 2.

⇒ При предоставлении разрешения Приложение 1 информируется

⇒ Приложение 1 запрашивает у Приложения 2 новый токен доступа, используя временный токен.

⇒ Приложение 2 одобряет запрос и отправляет новый токен доступа.

⇒ Приложение 1 теперь может получить доступ к данным Приложения 2, используя новый токен доступа.

ОАут 2.0

⇒ пользователь A хочет, чтобы приложение 1 имело доступ к данным в приложении 2.

⇒ Приложение 1 запрашивает доступ к приложению 2 с сервера авторизации.

⇒ пользователь A аутентифицируется на сервере авторизации с этими учетными данными, полученными на шаге выше, и возвращает разрешение на авторизацию в приложение 1 для доступа к данным в приложении 2.

⇒ Теперь приложение 1 запрашивает токен доступа с сервера авторизации, используя грант авторизации, который пользователь А предоставил на шаге 3 выше.

⇒ Сервер авторизации проверяет запрос и отправляет токен доступа в приложение 1.

⇒ Приложение 1 теперь может получать доступ к данным в приложении 1 с токеном доступа.

Почему OAuth 2.0?

• Улучшенная поддержка небраузерных приложений

• Разделение ролей

• Кратковременный токен доступа и токен обновления

• Уменьшена сложность подписания запросов.