Простое понимание OAuth 2.0

Адрес личного блога:blog.sqdyy.cn

Проблемы, которые должен решить OAuth2

Проблемы с авторизацией в открытой системе

Первоначально OAuth2 был предложен исходя из проблемы авторизации между открытыми системами, предполагается, что теперь есть стороннее приложение: «сервис облачной печати», который может печатать фотографии, хранящиеся у пользователей в Google. Чтобы использовать эту услугу, пользователи должны позволить «службе облачной печати» прочитать свои фотографии, хранящиеся в Google. Проблема в том, что Google разрешает «службе облачной печати» читать эти фотографии только с разрешения пользователя. Так как же «Служба облачной печати» получает авторизацию пользователя?

Способ 1: Скопируйте пароль и имя пользователя

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

Способ 2: мастер-ключ

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

Способ 3: Специальный жетон

Третий метод заключается в использовании специального токена, который может получить доступ только к защищенным ресурсам.Этот метод намного надежнее, чем первые два метода, и он близок к практике OAuth2, но как управлять токеном, требует некоторого внимания. для выпуска токенов и отзыва токенов. Мы оставим это до внедрения OAuth2 позже.

Современные проблемы безопасности микросервисов

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

Условно говоря, традиционные монолитные приложения — это в основном веб-приложения, ориентированные непосредственно на пользователей ПК, для современных микросервисных архитектур вышеописанный подход неприменим. Для современной микросервисной архитектуры степень детализации разделения между службами невелика, и необходимо учитывать проблему аутентификации между службами и службами.Кроме того, формы приложений стали разнообразными, такими как одностраничные приложения, беспроводные нативные приложения, серверное приложение. В этом сценарии мы обычно разрабатываем независимую службу, делаем аутентификацию и авторизацию AuthServer и выполняем аутентификацию и авторизацию в форме токена, так что это также серьезная проблема, решаемая OAuth2, которую мы представим позже.

Основные понятия OAuth

OAuth2.0 — это структура делегированной авторизации для REST/API, основанная наТокен, что позволяет приложениям получать ограниченный доступ к данным пользователя, не раскрывая пароль пользователя. Oauth 2.0 может разделить аутентификацию и авторизацию.Это стандартная структура безопасности де-факто, которая поддерживает несколько сценариев приложений, таких как серверное веб-приложение, браузерное одностраничное приложение SPA, беспроводное/собственное приложение, вызовы между серверами и т. д. Подождите.

OAuth2.0 имеет следующие преимущества:

Клиент не трогает пользовательский пароль, а сервер проще централизованно защитить
Широкое и устойчивое внедрение
Поддерживает краткосрочные и инкапсулированные токены
Разделение сервера ресурсов и сервера авторизации
Централизованная авторизация, упрощенный клиент
Совместимость с HTTP/JSON, легко запросить и передать токен
Рассмотрите несколько сценариев клиентской архитектуры
Клиенты могут иметь разный уровень доверия

Недостатки OAuth2.0:

Структура протокола слишком широка, что приводит к плохой совместимости и взаимодействию различных реализаций.
Не совместим с OAuth1.0

OAuth необходимо обратить внимание на:

OAuth не поддерживаетсяПротоколы, отличные от HTTP.
OAuth не являетсяПротокол аутентификации.
OAuth не определенМеханизм обработки авторизации.
OAuth не определенТип токена.
OAuth2.0 не определяетметод шифрования.
OAuth2.0 нене замужемпротокол.
OAuth2.0 — это только структура авторизации, которая используется только для прокси-серверов авторизации.

Основные роли и термины OAuth

Клиентское приложение: обычно веб-приложение или приложение для беспроводной связи, которому требуется доступ к защищенным ресурсам пользователя.
Сервер ресурсов: это веб-сайт или API веб-службы, где хранятся защищенные данные пользователя.
Авторизованный сервер: после успешной аутентификации и авторизации клиентского приложения клиентскому приложению выдается токен доступа.
Владелец ресурса: Владелец ресурса, который хочет поделиться некоторыми ресурсами со сторонними приложениями.
Учетные данные клиента: clientId и пароль клиента используются для аутентификации клиента.
Токены: сервер авторизации выдает токен доступа после получения запроса пользователя.
Сферы: когда клиент запрашивает токен доступа. Дополнительные права подразделения, указанные владельцем ресурса (разрешение)

Тип токена OAuth

ТокенЭто основная концепция OAuth 2.0.Токен можно сравнить с ключом Valet, который предоставляет ограниченный доступ к приложению, позволяя приложению получать доступ к данным пользователя от имени пользователя.

Токен кода авторизации: используется только для типа предоставления кода авторизации, используется в обмен для получения токена доступа и токена обновления.
Обновить токен: Используется для получения нового токена с сервера авторизации.
Токен доступа: используется для прямого доступа к защищенным ресурсам от имени пользователя или службы.
Bearer Token: тот, кто получит токен, может получить доступ к ресурсу.
Proof of Possession(Pop) Token: вы можете проверить, является ли клиент явным владельцем токена.

Метод авторизации OAuth2

Давайте сначала посмотрим на запущенный процесс OAuth2.0:

(A) После того, как пользователь открывает клиент, клиент запрашивает у пользователя авторизацию.
(B) Пользователь соглашается предоставить Клиенту авторизацию.
(C) Клиент использует авторизацию, полученную на предыдущем шаге, для запроса маркера с сервера аутентификации.
(D) После того, как сервер аутентификации аутентифицирует клиента, он подтверждает правильность и соглашается выдать токен.
(E) Клиент использует токен для обращения к серверу ресурсов для получения ресурса.
(F) Сервер ресурсов подтверждает правильность токена и соглашается открыть ресурс клиенту.

Шаг B здесь является ключом, то есть как клиент авторизует клиента.При такой авторизации клиент может получить токен, а затем использовать токен для получения ресурсов.OAuth2.0 предоставляет нам 4 режима для получения клиентом авторизация. :

Код авторизации
Упрощенный режим (неявный)
Режим пароля (учетные данные пароля владельца ресурса)
Режим клиента (учетные данные клиента)

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

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

Его шаги следующие:

(A) Пользователь обращается к клиенту, и клиент направляет пользователя на сервер аутентификации, который должен содержать учетные данные идентификатора клиента и URI перенаправления.
(B) Пользователь выбирает, авторизовать ли клиента.
(C) Предполагая, что пользователь предоставляет авторизацию, сервер аутентификации направляет пользователя на предварительно заданный URI перенаправления, сопровождаемый кодом авторизации.
(D) После того, как клиент получает код авторизации, внутренний сервер (невидимый для пользователя) передает заранее заданный URI перенаправления и код авторизации для подачи заявки на токен на сервер аутентификации.
(E) Сервер аутентификации проверяет код авторизации и URI перенаправления и после подтверждения их правильности выдает клиенту токен доступа и токен обновления.

упрощенный режим

Упрощенный режим не дорабатывается серверной программой По сравнению с режимом кода авторизации шаг "кода авторизации" уменьшен Браузер напрямую отправляет запрос на получение токена Токен виден посетителю, а клиент не требует аутентификации Эти режимы обычно используются для одностраничных приложений:

Его шаги следующие:

(A) Пользователь обращается к клиенту, и клиент направляет пользователя на сервер аутентификации, который должен содержать учетные данные идентификатора клиента и URI перенаправления.
(B) Пользователь выбирает, авторизовать ли клиента.
(C) Предполагая, что пользователь предоставляет авторизацию, сервер аутентификации направляет пользователя на URI перенаправления, указанный заранее, и включает токен доступа (фрагмент) в хэш-часть URI.
(D) Браузер отправляет на ресурсный сервер запрос, который не содержит полученной заранее хэш-части (фрагмента).
(E) Сервер ресурсов возвращает сценарий, содержащий код для получения токена в разделе Hash.
(F) Браузер выполняет полученный заранее скрипт и извлекает токен
(G) Браузер отправляет токен клиенту.

режим пароля

В режиме пароля пользователь предоставляет имя пользователя и пароль клиенту, и клиент использует эту информацию, чтобы напрямую запрашивать авторизацию у сервера аутентификации. Этот режим нарушает вышеупомянутую проблему безопасности микросервиса (не раскрывая имена пользователей и пароли), но в некоторых случаях, когда пользователи имеют высокое доверие к клиенту, например, при авторизации между программами внутри компании, этот режим используется.Также применяется:

Его шаги следующие:

(A) Пользователь предоставляет клиенту имя пользователя и пароль.
(B) Клиент отправляет имя пользователя и пароль на сервер аутентификации и запрашивает у сервера аутентификации токен.
(C) После того, как сервер аутентификации подтвердит правильность, он предоставляет токен доступа клиенту.

клиентский режим

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

Его шаги следующие:

(A) Клиент аутентифицируется на сервере аутентификации и запрашивает токен доступа.
(B) После того, как сервер аутентификации подтвердит правильность, он предоставляет токен доступа клиенту.

обновить токен

Если срок действия «токена доступа» клиента истек при доступе пользователя, вам необходимо использовать «токен обновления», чтобы подать заявку на новый токен доступа:

Его шаги следующие:

(A) Клиент аутентифицируется на сервере аутентификации и запрашивает токен доступа.
(B) После того, как сервер аутентификации подтвердит правильность, он возвращает токен доступа и токен обновления.
(C) Клиенты получают доступ к защищенным ресурсам через токены доступа.
(D) Если срок действия маркера доступа не истек, отдайте ресурс клиенту.
(E) Клиенты получают доступ к защищенным ресурсам через токены доступа.
(F) Если срок действия токена доступа истек, сервер защищенных ресурсов возвращает ошибку недопустимого токена.
(G) После того, как клиент получит вышеуказанную ошибку, он запрашивает новый токен доступа с сервера авторизации, обновляя токен.
(H) После того, как сервер аутентификации подтвердит правильность, он возвращает токен доступа и токен обновления.

Выбор четырех режимов OAuth2.0

Выше представлены 4 режима авторизации клиента OAuth.Технический выбор этих 4 режимов описан ниже.До этого будут предвосхищены две концепции:

Каналы процесса авторизации (каналы):Ранее упоминались четыре основные роли OAuth2.Взаимодействие между этими четырьмя ролями можно разделить на два типа каналов.Отправочное взаимодействие между владельцами ресурсов, клиентскими приложениями и серверами авторизации можно разделить на два типа:Интерфейсный канал. Любое взаимодействие между сервером авторизации, клиентским приложением и сервером ресурсов можно разделить навнутренний канал.

Тип заявки клиента:Приложения клиентов также можно разделить на две категории приложений, первая категорияпубличное приложение, в основном относится к одностраничному приложению SPA или собственному приложению, такие приложения находятся в руках пользователя, такие приложения не могут хранить учетную информацию пользователя, такую как пароли, обычно хранится только идентификатор пользователя. Вторая категориячастное приложение, в основном относится к приложениям веб-сервера, службам/API (от машины к машине), которые работают на бэкенде, в целом относительно безопасны и могут хранить учетные данные пользователя.

Особенности четырех режимов авторизации OAuth2.0

Перед выбором подытожим характеристики четырех типов авторизации:

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

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

упрощенный режим

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

Режим имени пользователя и пароля

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

клиентский режим

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

Выбор режима авторизации

Исходя из вышеизложенного, при выборе моделей можно руководствоваться следующими блок-схемами:

Ссылки на эту статью:

[Ян Бо учителя Micro Service Фактический бой 160]:time.geekhelp.org/course/int R…
[Понимание OAuth 2.0 Ruan Yifeng]:Вууху. Руан Ифэн.com/blog/2014/0…
[Проект входа: технология аутентификации в традиционных веб-приложениях Чен Цзицзе]:инсайты.мысль worker.org/традиционный…