В этой главе мы обсудим архитектурный стиль OAuth 2.0.
Шаг 1. Сначала пользователь получает доступ к ресурсам с помощью клиентского приложения, такого как Google, Facebook, Twitter и т. Д.
Шаг 2 — Далее клиентскому приложению будет предоставлен идентификатор клиента и пароль клиента во время регистрации URI перенаправления (универсального идентификатора ресурса).
Шаг 3 — Пользователь входит в систему, используя приложение для аутентификации. Идентификатор клиента и пароль клиента являются уникальными для клиентского приложения на сервере авторизации.
Шаг 4 — Сервер аутентификации перенаправляет пользователя на универсальный идентификатор ресурса (URI) перенаправления с использованием кода авторизации.
Шаг 5 — Пользователь получает доступ к странице, расположенной по адресу URI перенаправления в клиентском приложении.
Шаг 6 — Клиентское приложение получит код аутентификации, идентификатор клиента и пароль клиента и отправит их на сервер авторизации.
Шаг 7 — Приложение аутентификации возвращает токен доступа клиентскому приложению.
Шаг 8 — Как только клиентское приложение получает токен доступа, пользователь начинает доступ к ресурсам владельца ресурса с помощью клиентского приложения.
OAuth 2.0 имеет различные концепции, которые кратко описаны в следующей таблице.
OAuth предлагает несколько дополнительных терминов для понимания концепции авторизации.
Веб-сервер доставляет веб-страницы и использует HTTP для предоставления пользователям файлов, которые формируют веб-страницы.
Приложение агента пользователя используется клиентскими приложениями на устройстве пользователя, которое выступает в качестве экземпляра языка сценариев.
Собственное приложение можно использовать в качестве экземпляра приложения для настольного компьютера или мобильного телефона, в котором используются учетные данные владельца ресурса.