Введение

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

Конечно, весьма вероятно, что после авторизации получения информации о пользователе на стороннем веб-сайте вам потребуется заполнить некоторую необходимую информацию на этом веб-сайте для привязки, такую ​​как номер мобильного телефона, имя пользователя и так далее.

Но это намного удобнее, чем простая регистрация, и пользователям это тоже легко принять.

Сегодня мы объясним состав фреймворка авторизации OAuth 2.0, надеюсь, вам понравится.

Состав OAuth

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

Как мы это делаем в OAuth2?

Давайте сначала посмотрим на блок-схему авторизации в OAuth2:

Вообще говоря, в OAuth2 есть 4 роли.

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

сервер ресурсов: представляет сервер, которому в конечном итоге требуется доступ к ресурсу. Например, информация о пользователе, полученная после авторизации на github.

клиент: клиент, используемый для взаимодействия вместо владельца ресурса.

сервер авторизации: сервер, используемый для авторизации, который может генерировать соответствующий токен доступа.

Весь процесс выглядит так:

Клиент инициирует запрос авторизации владельцу ресурса, владелец ресурса вводит соответствующую информацию аутентификации и возвращает разрешение на авторизацию клиенту.

Затем клиент запрашивает у сервера авторизации полученное разрешение на авторизацию и возвращает токен доступа.

Затем клиент может использовать этот токен доступа, чтобы запросить сервер ресурсов и, наконец, получить ограниченный ресурс.

refresh Token

Из соображений безопасности токен доступа всегда имеет срок действия, что делать, если срок действия токена истек?

Конкретный способ - обновить токен:

Давайте посмотрим на блок-схему токена обновления:

Предыдущие процессы A, B, C и D аналогичны упомянутым выше.

Если срок действия токена доступа истекает при следующем доступе к ресурсу, клиент снова отправит запрос токена обновления в службу проверки подлинности.

Затем сервер аутентификации снова вернет новый токен доступа.

Режим кода авторизации

В режиме, упомянутом выше, клиент сохранит информацию о предоставлении авторизации и использует эту информацию для авторизации сервера для запроса маркера доступа.

Клиент напрямую сохраняет информацию о предоставлении авторизации и взаимодействует с сервером авторизации, который имеет определенные ограничения безопасности для клиента.

Если он находится в веб-среде, как клиент должен получить к нему доступ с помощью пользовательского агента (веб-браузера)?

Здесь представлен режим кода авторизации.

Клиент инициирует запрос через User-Agent со ссылкой перехода. Когда информация об авторизации и аутентификации пользователя предоставлена, сервер авторизации возвращает не токен, а код авторизации.После получения этого кода клиент может использовать этот код для получения токена доступа или токена обновления.

Мы можем использовать конкретный пример, чтобы проиллюстрировать приведенную выше блок-схему авторизации.Владелец ресурса — это ресурс, к которому мы хотим получить доступ. Сервер авторизации — это сторонний сервер авторизации, такой как служба авторизации github. User-Agent — это браузер.

Что ж, приступим к объяснению конкретного процесса:

Например, если пользователь хочет получить информацию о www.flydean.com, но ему нужно войти в систему, он перейдет к интерфейсу входа в систему github.Мы вводим имя пользователя и пароль github, и github вернет код авторизации. на наш сервер, напримерwww.flydean.com/?code=code, После того, как клиент получит код, он перейдет в фоновый режим, чтобы запросить github для проверки легитимности кода.Если код является законным, github вернет информацию о токене доступа, и клиент может использовать токен доступа, чтобы перейти к ресурс сервера ресурсов github.

Приведите пример возвращаемого значения конкретного токена доступа:

     HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
     }

Неявный грант

В режимах, упомянутых выше, клиент должен связаться напрямую с сервером авторизации, чтобы получить токен доступа.Есть ли способ получить токен доступа без необходимости, чтобы клиент напрямую связывался с сервером авторизации?

Далее поговорим о неявной авторизации.

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

Здесь нам нужно сделать дополнительный запрос к серверу клиентских ресурсов, и сервер вернет скрипт, через который мы разбираем фрагмент токена доступа, чтобы получить окончательный токен доступа.

Аутентификация пароля авторизации владельца ресурса

Этот режим обычно возникает, когда владелец ресурса очень доверяет клиенту.

Давайте сначала посмотрим на блок-схему:

Этот режим фактически эквивалентен тому, что пользователь передает пароль клиенту на хранение, а клиент использует сохраненные имя пользователя и пароль для запроса ресурсов с сервера авторизации.

Аутентификация и авторизация клиента

В этом режиме сам клиент имеет определенную область авторизации и может напрямую получить токен доступа сервера авторизации через аутентификацию и авторизацию клиента.

процесс аутентификации OAuth2 на github

В общем процессе, упомянутом выше, на самом деле можно совмещать многие роли.

Далее мы объясним, как использовать OAuth2 github для авторизации.

Чтобы использовать OAuth2 github, вам необходимо сначала зарегистрировать службу OAuth в github.

Нажмите кнопку регистрации, введите соответствующую информацию, и мы можем завершить регистрацию.

Более важным здесь является URL-адрес обратного вызова, мы будем передавать информацию авторизации через этот URL-адрес обратного вызова.

После успешной регистрации вы получите Client ID и Client Secret.

Шаги авторизации github разделены на три части:

Пользователь переходит на страницу аутентификации github для авторизации

В этой части нам нужно перейти на страницу авторизации github:

https://github.com/login/oauth/authorize

Выше приведена ссылка на страницу перехода, которая может принимать следующие параметры:

client_id: обязательный параметр, который является идентификатором клиента, полученным приложением, которое мы зарегистрировали выше.

redirect_uri: необязательный параметр, если он не установлен, будет использоваться uri обратного вызова, указанный при регистрации.

login: необязательный параметр, указывающий конкретное имя пользователя для аутентификации.

scope: Область разрешений в github.

состояние: это случайное число, используемое для предотвращения межсайтовых атак.

allow_signup: разрешать ли регистрацию во время аутентификации.

Взгляните на пропущенную страницу:

Пользователь возвращается на страницу ресурса, чтобы получить доступ

Когда пользователь авторизуется, он подстроится под страницу обратного вызова и выведет код:

http://www.flydean.com/login?code=b14a2dd57f11b2310f42

После того, как приложение получит код, оно получит токен доступа, вызвав следующий запрос:

POST https://github.com/login/oauth/access_token

Этот почтовый запрос должен содержать три обязательных параметра client_id, client_secret, code и два необязательных параметра redirect_uri и state.

По умолчанию мы получим следующую информацию об ответе:

access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer

Приложение получает токен доступа для получения информации о пользователе github.

После того, как у нас есть токен доступа, нам нужно поместить токен в заголовок запроса, чтобы запросить информацию о пользователе:

Authorization: token OAUTH-TOKEN
GET https://api.github.com/user

Суммировать

OAuth2 — очень распространенный протокол, к тому же очень удобный, основная цель — дать возможность сторонним серверам получать информацию о пользователе в рамках авторизации. Надеюсь, всем понравится.

Автор статьи: о программе flydean

Ссылка на эту статью:woohoo. Флойд press.com/OAuth-2-0-i…

Источник этой статьи: блог flydean

Добро пожаловать на мой официальный аккаунт: самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!