Как работает Oauth 2.0
Oauth 2.0, что означает «Открытая авторизация», представляет собой структуру авторизации, которая позволяет приложению получать ограниченный доступ к вашей учетной записи на другой службе https. Это делается путем делегирования авторизации приложению, в котором размещены пользовательские данные, из стороннего приложения.
По сути, это похоже на предоставление приложению ключа, который дает им конкретное разрешение на доступ к данным и выполнение действий от имени пользователя в другом приложении. Это позволяет пользователю предоставлять ограниченный доступ к учетной записи пользователя в другой службе клиентскому приложению без указания имени пользователя или пароля. Пользователь может отозвать разрешение в любой момент.
Шаги по предоставлению разрешения часто называют авторизацией или делегированной авторизацией.
Давайте посмотрим на пример.
Клиентское приложение - это приложение, которое отправляет приветственные электронные письма от имени пользователя. Это приложение требует разрешения на отправку электронных писем и доступ к контактам от имени пользователя, и они поддерживают авторизацию Oauth 2.0 для поставщика электронной почты (например, Gmail или Outlook), который использует пользователь.
Когда выбран поставщик услуг электронной почты, пользователь перенаправляется на службу электронной почты. Провайдер электронной почты проверяет, вошел ли пользователь в систему. Если нет, пользователю будет предложено войти в систему.
После входа в систему пользователю будет показан экран с разрешением, которое будет предоставлено клиентскому приложению. Это может быть принято или отклонено пользователем. Как только пользователь предоставит разрешение, он будет перенаправлен в исходное приложение. Теперь приложение может получить доступ к контакту пользователя и отправлять электронные письма от его имени.
Этот поток известен как поток кода авторизации. Ничто из этого не может показаться новым для читателя, поскольку мы часто наблюдаем этот поток в нашей повседневной жизни в Интернете.
Давайте подробно рассмотрим работу Oauth 2.0.
Терминология
Во-первых, давайте посмотрим на различные термины, присутствующие в потоке Oauth 2.0.
* Владелец ресурса * - пользователь, который предоставляет клиентскому приложению доступ к некоторой части данных своей учетной записи.
Client - приложение, которому требуются данные или разрешения.
Authorization Server - это сервер, который знает владельца ресурса. Пользователь будет взаимодействовать с сервером авторизации, когда приложение запрашивает доступ к его учетной записи. Сервер авторизации предложит пользователям предоставить разрешение клиенту.
Resource Server - API/сервер, содержащий данные пользователя, к которым обращается клиентское приложение. Сервер ресурсов должен иметь возможность принимать и проверять токены доступа и предоставлять доступ, если пользователь разрешил это.
Redirect URI - URI, на который сервер авторизации перенаправит владельца ресурса обратно после предоставления разрешения. Это также известно как URI обратного вызова.
Response Type - это тип ответа, которого ожидает клиент. Он информирует Authorization Server о желаемом потоке обработки авторизации. Обычный тип ответа - «код».
Scope - это отдельные разрешения, необходимые клиентскому приложению. Приложение может запрашивать одну или несколько областей. Значение областей не стандартизировано и зависит от внутренней архитектуры службы.
Consent - сервер авторизации берет запрошенную клиентом область действия и проверяет ее у владельца ресурса, хотят ли они предоставить разрешение. Пользователю будет предложена форма согласия относительно объемов.
Client Id - это значение, которое используется для однозначной идентификации клиентского приложения.
Client Secret - это, по сути, собственный пароль клиентского приложения к серверу авторизации. Это секрет, известный только приложению и серверу авторизации.
Authorization Code - этот код представляет собой кратковременное значение, которое сервер авторизации отправляет обратно клиенту. Клиент отправит код авторизации обратно на сервер авторизации вместе с секретом клиента в обмен на токен доступа.
Access Token - это ключ, который клиентское приложение использует для выполнения запроса API от имени пользователя. Это позволяет приложению получать доступ к определенным частям данных пользователя. OAuth 2.0 не определяет конкретный формат для токенов доступа. Формат JSON Web Token (JWT) часто используется для токенов доступа. По соображениям безопасности токены доступа могут иметь срок действия.
Код авторизации: под капотом
Теперь, когда терминология Oauth 2.0 понятна, давайте подробно рассмотрим поток кода авторизации.
Прежде чем пользователи появятся в кадре, клиентское приложение свяжется с сервером авторизации и установит рабочие отношения. Сервер авторизации сгенерирует идентификатор клиента и секрет клиента (иногда известный как идентификатор приложения или секрет приложения), которые можно использовать в будущих сообщениях.
Когда пользователь взаимодействует с клиентским приложением и выбирает службу, он будет перенаправлен на сервер авторизации с запросом, содержащим идентификатор клиента, URI перенаправления, тип ответа и требуемые области.
Сервер авторизации проверит пользователя и запрос. Он предложит пользователю войти в систему, если пользователь не вошел в систему. Области, запрошенные клиентским приложением, будут представлены пользователю на экране согласия. Это позволит пользователю предоставлять или отклонять разрешения.
Как только пользователь предоставит разрешение серверу авторизации, он будет перенаправлен для перенаправления URI вместе с временным кодом авторизации.
Затем клиент свяжется с сервером авторизации напрямую, сообщив идентификатор клиента, секрет клиента и код авторизации. Сервер авторизации ответит токеном доступа. Этот токен доступа может использоваться клиентом в будущих взаимодействиях для доступа к данным и выполнения операций от имени пользователя на сервере ресурсов.
В этой статье мы кратко рассмотрели некоторые концепции, связанные с Oauth 2.0 и его рабочим процессом.
Надеюсь, эта статья была полезной.