Авторизация между сервисами через OAuth 2.0

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

OAuth обеспечивает делегированный доступ. Эту концепцию можно пояснить на примере Valet Key. Во многих отелях клиенты могут передать ключи от машины парковщику для парковки от их имени. Чтобы предотвратить кражу, некоторые автомобили поставляются с ключом камердинера, доступ к которому ограничен. В этом примере сервису камердинера необходим доступ к автомобильному сервису, для которого клиент предоставляет только необходимый набор услуг с помощью ключа камердинера. Это представляет собой делегированный доступ.

Рисунок: Войдите в систему через Google, Facebook, который использует OAuth для авторизации сторонней службы для доступа к данным пользователя.

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

Элементы OAuth:
Чтобы описать элементы, задействованные в OAuth, мы выберем пример сценария, в котором может использоваться OAuth. Учтите, что клиентам онлайн-службы печати фотографий требуется функция, которая позволяет службе печати напрямую загружать фотографии пользователей из их учетной записи Google Фото. Чтобы реализовать такую функцию, тривиальный подход будет включать службу печати, запрашивающую учетные данные пользователя для его учетной записи Google. Очевидно, что такой подход крайне небезопасен, поскольку пользователи не могут доверять службе печати доступ ко всей своей учетной записи Google. Здесь на помощь приходит OAuth.

Терминология, используемая для описания участников / элементов в системе OAuth:

1. Ресурс -
   Он представляет данные, к которым должен получить доступ сторонний сервис. В нашем примере фотографии пользователя представляют ресурс.
2. Владелец ресурса -
   Владелец ресурса является фактическим владельцем ресурса. В нашем сценарии первоначальным владельцем фотографий является владелец ресурса.
3. Клиент -
   Клиент представляет стороннюю службу, которая требует доступа к Ресурсу от имени Владельца Ресурса. В нашем примере клиентом является служба фотопечати.
4. Сервер ресурсов -
   Он представляет собой сервер, на котором надежно хранится Ресурс. В нашем примере фотографии размещаются на сервере Google, который действует как сервер ресурсов.
5. Сервер авторизации (Сервер аутентификации) -
   Для реализации протокола OAuth необходимо предоставить дополнительный сервер субъектом, который владеет сервером ресурсов, т. Е. Google, поскольку Google размещает ресурсы и несет бремя безопасности.

Вместо предоставления функциональности Auth Server на самом сервере ресурсов, отдельный сервер используется для уменьшения ненужной перегрузки на сервере ресурсов.

Процесс OAuth:

Процесс OAuth протекает следующим образом:

1. Владелец ресурса запрашивает у Клиента услугу, в нашем случае - печать фотографий.
2. Клиент связывается с AuthServer для запроса ресурса, т. Е. Фотографий на серверах Google. Сервер аутентификации отправляет запрос владельцу ресурса с запросом, полученным от клиента, в виде окна входа в систему от Google.
3. Пользователь подтверждает, что услуги, запрошенные Клиентом, и предоставляет авторизацию серверу Auth от имени Клиента. Это обеспечивает делегированный доступ к Client.
4. Сервер аутентификации получает запрос на авторизацию от Владельца ресурса.
5. При аутентификации и подтверждении от владельца ресурса Auth Server отправляет клиенту токен доступа, разрешающий ему доступ к необходимым ресурсам, размещенным на сервере ресурсов.
6. Клиент предоставляет токен доступа серверу ресурсов.
7. После проверки токена доступа клиенту предоставляется ресурс.
8. Наконец, пользователь может получить доступ к службам клиента, которые могут получать доступ к защищенным ресурсам от имени пользователя.

Подробно описанный выше поток называется неявным потоком . В некоторых потоках OAuth вместо прямого предоставления клиенту токена доступа промежуточный токен авторизации может быть предоставлен сервером аутентификации клиенту. Чтобы получить доступ к ресурсу, клиент должен сначала предоставить токен авторизации серверу аутентификации и запросить токен доступа. Такой поток OAuth известен как поток кода авторизации.

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

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

Вниманию читателя! Не переставай учиться сейчас. Получите все важные концепции теории CS для собеседований SDE с курсом теории CS по доступной для студентов цене и будьте готовы к отрасли.