Объяснение OAuth 2.0
Обычный процесс входа в систему
Самый простой способ войти на сайт - ввести имя учетной записи и соответствующий пароль. Затем сервер берет эту информацию и ищет информацию, которая соответствует заданным ID и PW в своей базе данных. Если вся данная информация соответствует учетным данным в БД, сервер возвращает 200 или 4xx, 5xx. Это просто и легко. Потому что соединение было между конечным пользователем и сервером.
Однако что вы должны сделать, чтобы пользователи могли читать и приносить свои расписания Календаря Google? Конечно, самый простой способ - попросить их данные для входа в Google. Но это очень опасный и никогда не рекомендуемый способ обеспечения.
Вот когда приходит OAuth.
Что такое OAuth?
Согласно SearchAppArchitecture, они описывают, что такое OAuth, следующим образом.
OAuth (открытая авторизация) - это открытая стандартная структура авторизации для авторизации на основе токенов в Интернете. OAuth, которое произносится как «о-автори», позволяет использовать информацию учетной записи конечного пользователя сторонними службами, такими как Facebook и Google, без раскрытия учетных данных пользователя третьей стороне.
Проще говоря, OAuth позволяет пользователям использовать функции сторонних сервисов. Например, когда пользователь входит в Medium и пытается вызвать события, зарегистрированные в Google Calander, пользователя просят войти в Google, а не в Medium. После успешного входа в систему пользователь может получать расписания. Это то, что такое OAuth.
Условия
Поскольку термины и концепция OAuth будут одинаковыми в зависимости от сервиса, для поддержки OAuth 2.0 нам необходимо проверить правильность терминов, используемых в RFC-6749, спецификации OAuth 2.0.
👇 В приведенной ниже функции показаны значки, которые я собираюсь использовать в этой публикации, чтобы объяснить, как работает OAuth.
- Владелец ресурса: обычно это лицо, обладающее информацией, включая данные для входа в систему, которая необходима для использования предоставляемых услуг, например, любой пользователь, использующий эту услугу.
- Клиент: приложение, предоставляющее защищенные ресурсы, такие как изображения, содержимое или что-то подобное, например, Medium является клиентом в предыдущем примере.
- Сервер ресурсов: сервер, на котором размещены ресурсы. Это может быть сервер Google, который предоставляет ресурсы календаря.
- Сервер авторизации: сервер предоставляет клиенту токен доступа, необходимый для использования дополнительных API.
Как работает OAuth
Вы хотите войти в Medium со своим идентификатором Twitter, но на самом деле вы не хотите создавать новую учетную запись. Слишком много работы, не правда ли?
Допустим, пользователь, владелец ресурса, хочет войти в систему через Twitter. Тогда общая картина будет видна, как на рисунке выше. Клиент, ваше приложение, показывает владельцу ресурса кнопку входа в систему. После нажатия кнопки владелец ресурса может увидеть страницу входа в систему.
Когда владелец ресурса пытается войти в систему, клиент должен спросить владельца ресурса, разрешает ли владелец ресурса доступ сторонней службе к фотографиям, профилю или чему-то в этом роде. Если владелец ресурса соглашается с этим, сервер авторизации запрашивает его учетные данные, такие как имя учетной записи и пароль.
После успешного входа владельца ресурса сервер авторизации возвращает клиенту токен доступа. Это требуется для получения других API в Twitter (например).
В большинстве случаев токен доступа имеет истекшее время (может быть, я мог бы назвать это TTL?), Который обычно составляет менее 60 минут. По истечении срока его действия клиент может получить новый токен доступа, используя другой токен, называемый токеном обновления. Конечно, этот токен обновления также истечет в один прекрасный день, тогда клиент должен будет сделать тот же шаг, запросив у владельца ресурса данные для входа и бла-бла, чтобы получить новый токен доступа.
С заданным токеном доступа клиент получает API Twitter, отправляя токен доступа в заголовке. Затем сервер ресурсов просит сервер авторизации проверить, действителен ли этот токен доступа для этого пользователя. Как только сервер авторизации говорит «Да, все в порядке» обратно серверу ресурсов, он возвращает запрошенные данные клиенту.
Немного глубже погрузиться в поток
Давайте углубимся в то, как работает этот поток. Чтобы получить токен доступа, вы должны заранее зарегистрировать свое приложение в сторонней службе, которую хотите использовать.
Например, когда вы создаете проект в API Google, вы можете получить два учетных данных: идентификатор клиента и секрет клиента. Обратите внимание, что вы не должны раскрывать эти ключи ни при каких обстоятельствах, особенно будьте очень осторожны с секретным ключом в вашем реальном проекте.
Есть еще кое-что, что нужно знать, это URL-адрес перенаправления, на который сервер авторизации отправит страницу после предоставления доступа, и область действия. Область действия в контексте OAuth относится к количеству функций, к которым клиент хочет получить доступ.
Клиент запрашивает код авторизации от сервера авторизации, отправляя идентификатор клиента, информацию об области действия и URL-адрес обратного вызова (URL-адрес перенаправления). Сервер авторизации проверяет, совпадает ли каждая полученная информация с информацией, которую он хранит. Если что-то из этого отличается, код авторизации не возвращается.
Скажем, Twitter API включает профиль, публикации, сообщения и лайки. Если область действия вашего клиента содержит только профиль и лайки, то сервер авторизации выдает вам код авторизации, который разрешает вам только доступ к профилю и лайкам.
С другой стороны, клиент, наконец, запрашивает у сервера авторизации токен доступа, отправляя тип разрешения, идентификатор клиента, секрет клиента, код авторизации и URL-адрес перенаправления. Тип разрешения - это «код авторизации», «неявный», «учетные данные пароля владельца ресурса» и «учетные данные клиента». Client Secret - это ключ, возвращенный при создании проекта.
Сервер авторизации проверяет, совпадает ли данный код авторизации с имеющимся у него кодом авторизации. Если он совпадает, то сервер авторизации проверяет секрет клиента и идентификатор клиента с теми же двумя ключами, которые хранятся в которых хранится код авторизации.
Если вся информация совпадает правильно, сервер авторизации возвращает токен доступа клиенту.
Клиент может получать API-интерфейсы Twitter с помощью токена доступа.
Вывод
Аутентификация OAuth более эффективна, чем та, что использовалась на сервере с отслеживанием состояния. Поскольку на сервере с отслеживанием состояния им приходилось сохранять сеансы входа в систему в памяти, поэтому это могло быть не только тяжелым, если количество пользователей огромное, но также сложнее общаться с другими серверами, когда есть более одного сервера. .
Однако с OAuth серверу не нужно беспокоиться о связи с другими серверами по поводу проблемы аутентификации. Что ж, еще нужно где-то сохранять информацию о токенах доступа.
Итак, есть еще один способ аутентификации, который называется JWT. Постараюсь написать об этом позже.
Процесс и концепция OAuth почти всегда одинаковы, какие бы сервисы вы ни использовали, которые поддерживают OAuth. Таким образом, как только вы поймете весь поток, вы больше не запутаетесь.
