Протокол аутентификации инвентаря: OAuth, OIDC, CAS в популяризации

Общая документация:Каталог статей
Github : github.com/black-ant

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

В этой статье в основном рассказывается об OAuth, OIDC, CAS, а что касается SAML, то я сильно сомневаюсь, что одной статьей не закончить....

Введение

Здесь я пытаюсь разделить протоколы на несколько категорий:

Чистый протокол ограничения: OAuth, SAML, OIDC, CAS
Протоколы класса сервера: RADIUS, Kerberos, ADFS
Метод аутентификации: OTP, биометрическая аутентификация (лицо, голос, отпечаток пальца)
Сервер аутентификации (в комплекте): AD, LDAP

В этой статье мы лишь популяризируем процесс, а далее последовательно разберем способ реализации.

1.1 Жетон предварительного знания

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

1.2 Предварительные знания JWT

Полное название JWT — веб-токен Json.JWT обычно состоит из трех частей:

Заголовок JWT: заголовок представлен в формате JSON.
- alg : алгоритм, используемый для подписи
- type : тип токена, унифицированный как JWT
Полезная нагрузка
- iss: Идентификатор эмитента: Требуется. Уникальный идентификатор лица, предоставившего аутентификационную информацию
- exp: Expiration time: Время истечения срока действия. Токены ID, которые превышают это время, будут недействительны и больше не будут проверяться.
- sub: Идентификатор субъекта: Тема. Логотип ЕС, предоставленный iss, уникален в рамках iss. Он будет использоваться RP для идентификации уникального пользователя.
- ауди: пользователь
- nbf: пока недоступно
- iat: Выпущено во время: время создания JWT.
- jti: идентификатор JWT используется для идентификации JWT.
- auth_time : AuthenticationTime : время, когда ЕС завершил аутентификацию
- acr : Ссылка на класс контекста аутентификации: необязательно. Представляет значение ссылки на контекст проверки подлинности, которое можно использовать для идентификации класса контекста проверки подлинности.
- amr : Ссылки на методы аутентификации: необязательно. Представляет набор методов аутентификации
- azp = уполномоченная сторона: необязательно. Используйте вместе с ауд. Это значение используется только в том случае, если сторона, прошедшая проверку подлинности, и аудитория (аудио) несовместимы и редко используются в целом.
подписать

2. Чистое ограничение

Чистый тип ограничения означает, что он выглядит как спецификация, и эту спецификацию реализуют разные фреймворки (на самом деле спецификацию еще называют фреймворком, то есть узким фреймворком)

2.1 Протокол OAuth

2.1.1 Обсуждение OAuth

Обычно мы говорим, что OAuth относится к своей версии 2.0, а теперь OAuth анонсировал свою версию 2.1, которая упрощена по структуре, OAuth не является законченной концепцией, на самом деле он состоит из множества различных RFC (RFC 6749, RFC 6750), они строят друг на друга и добавлять функции разными способами, как показано на следующей диаграмме:

@ Аарон боится жары CK i.com/2019/12/12/…

При разработке всего протокола OAuth одна за другой добавлялись многочисленные спецификации и реализовывались многочисленные функции..

НапримерRFC 6749Четыре типа авторизации, которые мы используем чаще всего, определены в: код авторизации, неявный, пароль и учетные данные клиента, а такжеRFC 7636PKCE (способ использования потока кода авторизации без секретов клиента),RFC 8252Для нативных приложений рекомендуется использовать файлы .

>>> До появления OAuth2.1 остаются следующие три типа:

Authorization code + PKCE
Client Credentials
Device Grant

В этой статье не будет слишком много OAuth2.1, в основном потому, что мой код реализации еще не написан...

Типы, поддерживаемые OAuth2.0:

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

2.1.2 Процесс OAuth 2.0:

Весь процесс OAuth примерно таков:

Шаг 1. Используйте метод для аутентификации и верните билет AccessToken после успешной аутентификации.(Это не ограничивается одношаговым завершением)
Шаг 2: Получите информацию о пользователе с возвращенным билетом

О процессе OAuth2.0 сказано слишком много в сети, и я думаю, он не будет лучше нарисован предшественниками, поэтому прямо процитирую его здесь:

Сводная классификация:

Вот различия между тремя:

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

Step 1: Authoriza - > code : Инициировать запрос и вернуть код
Step 2: Code -> Token : Код доступа в обмен на токен
Step 3: Token -> UserInfo : Pass Token в обмен на информацию о пользователе

неявный метод:Неявный метод представляет собой упрощенную версию кода, состоящую изStep1 Authorizaпришел прямоTokenшаг

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

Метод кода OAuth

Неявный метод OAuth

Метод пароля OAuth

Список интерфейсных запросов протокола OAuth

// Authoriza Code 模式
* 第一步 ： http://localhost:8080/oauth/authorize?response_type=code&client_id=pair&redirect_uri=http://baidu.com

> Response_type -> 返回类型
> Client_id-> 对应的client id 
> redirect_uri->重定向的地址 

* 第二步 ：
http://localhost:8080/oauth/token?grant_type=authorization_code&code=o4YrCS&client_id=pair&client_secret=secret&redirect_uri=http://baidu.com 

> grant_type
> code    
> client_id   
> client_secret   
> redirect_uri 

* 第三步 ：
通过Token 换取信息 ... 略

----------------------------
// implicit 模式 (略 , 第一步直接返回Code)


----------------------------
// Password 模式 (直接传入密码)
http://localhost:8080/oauth/accessToken?grant_type=password&client_id=b7a8cc2a-5dec-4a64&username=admin&password=123456

2.1.3 OAuth FAQ

Вопрос 1: Роль государства

вопрос :Когда атакуемый (гражданское А) входит в систему, пусть А думает, что логин - это его собственная учетная запись, но на самом деле логин - это заранее подготовленная атакующим (оборотнем Б) учетная запись, что приводит к операции, которая A делает на нем , B видны.

B Заранее подготовьте учетную запись для атаки, выполните первый шаг временной авторизации и получите Код.На данный момент базовая проверка завершена, и оставшийся доступ к серверу авторизации заключается в получении Токена доступа.
В это время B принудительно останавливает процесс самоаутентификации, обманывает A, чтобы щелкнуть, и позволяет A завершить последующий вход в систему с помощью Кода.В это время A думает, что он вошел в систему со своей собственной учетной записью, и думает, что он правильно вошел в систему.

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

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

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

Вопрос 3: Доработать

TODO ~~~~~

2.2 Протокол OIDC

После разговора об OAuth, конечно же, я хочу поговорить о младшем брате OIDC, который на самом деле очень прост.Это добавление концепции OpenID на основе OAuth., вы можете повторно использовать код OAuth для удобства, то есть использовать дополнительный JWT поверх OAuth для передачи информации о пользователе.

2.2.1 Введение в OIDC

OpenID Connetction : OIDC= (Identity, Authentication) + OAuth 2.0, который представляет собой стандартный протокол аутентификации на основе OAuth 2, который создает уровень идентификации через OAuth 2.0.

OIDC предоставляет токен ID для решенияСторонние клиенты идентифицируют личности пользователейВ процессе авторизации Oauth2 информация об аутентификации пользователя предоставляется стороннему клиенту, а токен ID упаковывается в формат JWT.(Благодаря всеобъемлющей компактности и защищенному от несанкционированного доступа механизму JWT, а также предоставлению информации о пользователе, вы можете вернуться к расширению JWT в начале)

Информация о составе OIDC

- core : 定义 OIDC 的核心功能 ，在OAuth 2 之上 构建身份认证 ，以及使用 Claims 来传递用户信息 
- Discovery :  发现服务  ,  用于客户端动态的获取OIDC 服务相关的元数据描述信息
- Dynamic Registration ： 动态注册服务 ， 使客户端可以动态的注册到OIDC 的 OP 
- OAuth 2.0 Multiple Response Types ：可选。针对OAuth2的扩展，提供几个新的response_type。
- OAuth 2.0 Form Post Response Mode：可选。针对OAuth2的扩展，OAuth2回传信息给客户端是通过URL的querystring和fragment这两种方式，这个扩展标准提供了一基于form表单的形式把数据post给客户端的机制。
- Session Management ：可选。Session管理，用于规范OIDC服务如何管理Session信息
- Front-Channel Logout：可选。基于前端的注销机制，使得RP（这个缩写后面会解释）可以不使用OP的iframe来退出
- Back-Channel Logout：可选。基于后端的注销机制，定义了RP和OP直接如何通信来完成注销

2.2.2 Процесс запроса OIDC

RP применяет к OP для авторизации, OP возвращает авторизационный токен доступа и идентификационный токен и использует токен доступа для запроса информации от конечной точки информации о пользователе.
Хотя запрос AuthN является запросом на авторизацию, который повторно использует OAuth 2, он имеет разные применения.Параметр области authN OIDC должен иметь параметр openid.

The RP (Client) sends a request to the OpenID Provider (OP).
The OP authenticates the End-User and obtains authorization.
The OP responds with an ID Token and usually an Access Token.
The RP can send a request with the Access Token to the UserInfo Endpoint.
The UserInfo Endpoint returns Claims about the End-User. 
  
+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+

// 详细步骤 : 
》 OIDC 单点登录流程
  > 1 . 用户点击登录 ，触发对OIDC-SERVER 的认证请求
     |-> request : 包含参数URL , 指向登录成功后的跳转地址
     |-> response ： 返回 302 ，Location 指向 OIDC-SERVER ，Set-Cookie 设置了 nonce的cookie
  > 2 . 向 OIDC-SERVER 发起 authc 请求
     |-> client_id=implicit-client ：发起认证请求的客户端的唯一标识
     |-> reponse_mode=form_post ：使用form表单的形式返回数据
     |-> response_type=id_token ：返回包含类型 id_token
     |-> scope=openid profile ：返回包含有openid这一项
     |-> state ：等同于OAuth2 state ，用于保证客户端一致性
     |-> nonce ： 写入的cookie 值
     |-> redirect_uri ： 认证成功后的回调地址
  > 3 . OIDC-SERVER 验证 authc 请求
     |-> client_id是否有效，redircet_uri是否合法 等一系列验证
  > 4 . 引导用户登录 ，以及用户登录 
     |-> resumeURL 
     |-> username + password     
  > 5 . 返回一个自动提交form 表单的页面
     |-> id_token：id_token即为认证的信息，OIDC的核心部分，采用JWT格式包装的一个字符串
     |-> scope：用户允许访问的scope信息
     |-> state : 类似
     |-> session_state ：会话状态    
  > 6 . 验证数据有效性，构造自身登录状态
     |-> 客户端验证id_token的有效性 ，保证客户端得到的id_token是oidc-sercer.dev颁发的

Демонстрация интерфейса OIDC ------------> Я действительно не помню случая с большим парнем....


// OIDC 直观流程 请求地址  :
// Step 1 : 发起 Authorize 请求 
https://${yourDomain}/oauth2/default/v1/authorize?response_type=code
&client_id=12345
&redirect_uri=https://proxy.example.com:3080/v1/webapi/oidc/callback
&scope=openid,email
&state=syl

// Step 2 : 认证成功后重定向返回
https://proxy.example.com:3080/v1/webapi/oidc/callback?code=pkzdZumQi1&state=syl

// Step 3 : 申请 Token
POST https://${yourOktaDomain}/oauth2/default/v1/token
?grant_type=authorization_code& 
code=pkzdZumQi1& 
redirect_uri=https://proxy.example.com:3080/v1/webapi/oidc/callback
client_id=12345& 
client_secret=gravitational
    
// Step 4 : AccessToken 返回
{
"id_token":"FW6AlBeyalZtDIRXxA0u5XBbZkLzjYzKUQBloxQXSSGPFmRS8eSfDu0A4nS4GF1aQP9PRxQk7gIh9bjaX99
aa4vDSzP1E2ajsgIomlNGhNxBqEDV5Exp0xISE9bZ4HUzM91pbzPPj7Bq5ZQUWcSuSVD0NAfkAoG6qDpbQfxPjWRyfthz3p
UEXwZe8Cz4eOXOM45UKB4Q0VnVSChVF84MWkeBFKzhrRNXd2dFv0HTlkQr6vXGlYsocMxR06wo38HvGiKjkUmL2YUyPOjZa
oUN4ovfwlwdGdjNR2GVcRsXzjxCPszJ9dTXztoL5wo2ycEpuxkkNp57BuZ9YRexoNnRHahFKH76XrFsTvdvAYk3fBVUqrO5
vvyxHAFrAIKpV0FvaMiBwKNfaE84oRC6aBXnzS3q4uVyGcHveHQMJB1temgB599rfVH3pBqurUmQCd0tVexRZj4PUkrDocf
8Z0QKkCD0eonH0Q1bRpQPY5vATiLkpF8RArU7wyB2FxhB3egtQBvwDgsVjyix7u8Cx4P9oy3IJje6SZfc6Lz61uEQttpVhy
qfzgFYUqVoQacw6rocCn3u61dM0moB"
"access_token":"IEZKr6ePPtxZBEd",
"token_type":"bearer",
"scope":"read:org",
"expires_in":3600
}

// Step 5 : 对 id_token 进行解码
{
    "sub":"virag",
    "iss":"https://${yourOktaDomain}/oauth2/",
    "aud":"client_12345",
    "iat":"1595977376",
    "exp":"1595980976",
    "email":"virag@goteleport.com",
    "email_verified":"true"
}

// Step 6 : 对资源进行请求

2.2.3 Расширенный документ OIDC

https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/

https://www.okta.com/identity-101/whats-the-difference-between-oauth-openid-connect-and-saml/

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols

https://yangsa.azurewebsites.net/index.php/2019/08/08/brief-summary-of-differences-between-oauth2-and-oidc/

https://www.c-sharpcorner.com/article/oauth2-0-and-openid-connect-oidc-core-concepts-what-why-how/

2.2.4 Дополнительные точки знаний OIDC

Спецификация обнаружения OIDC

Определяет спецификацию обнаружения службы, которая определяет API ( /.well-known/openid-configuration ), который возвращает структуру данных json, содержащую некоторые службы, предоставляемые в OIDC, и информацию об их поддержке. Таким образом, RP служба oidc больше не может жестко кодировать информацию об интерфейсе службы OIDC.

управление сессиями

Управление сеансом: необязательно. Управление сеансом, которое используется для стандартизации того, как служба OIDC управляет информацией о сеансе.
Выход из переднего канала: необязательно. Внешний механизм выхода из системы.
Выход из обратного канала: необязательно. Механизм выхода из системы на основе бэкенда.

Преимущества OIDC

OIDC позволяет аутентификации удостоверений существовать как службе.
OIDC может легко реализовать SSO (перекрестный домен).
OIDC совместим с OAuth2 и может использовать токен доступа для управления защищенными ресурсами API.
OIDC может быть совместим со многими IDP для использования в качестве OIDC OP.
Для некоторых конфиденциальных интерфейсов OIDC требуется TLS.Кроме того, благодаря механизму безопасности семейств JWT, JWS и JWE некоторая конфиденциальная информация может быть подписана цифровой подписью, зашифрована и проверена для дальнейшего обеспечения безопасности всего процесса аутентификации.

2.3 CAS

Я слишком хорошо знаком с CAS, поэтому не хочу со всеми говорить глупости~~~~

2.3.1 Терминология CAS

CAS разделен на две части: сервер CAS и клиент CAS.

Сервер CAS используется для аутентификации пользователя, точно так же, как здесь хранится идентификатор первого вошедшего в систему пользователя.
CAS Client — это разработанное нами приложение, которое необходимо подключить к CAS Server.

Три термина для CAS

Билет на предоставление билетов (TGT): его можно рассматривать как билет, сгенерированный сервером CAS на основе имени пользователя и пароля, которые существуют на стороне сервера.
- После кэширования он будет сотрудничать с TGC для генерации ST (поскольку TGT может идентифицировать пользователя, вошедшего в систему).
Файл cookie для предоставления билетов (TGC): Фактически, это файл cookie, в котором хранится информация об идентификаторе пользователя, и сервер отправляет его клиенту.
Сервисный билет (ST): одноразовый билет, созданный TGT для проверки и может быть использован только один раз.

2.3.2 Процесс обработки CAS

Пользователь впервые посещает веб-сайт, перенаправляется на клиент CAS, обнаруживает, что cookie-файлов нет (TGC или ST), и перенаправляется на страницу входа на сервер CAS.
Введите имя пользователя и пароль для аутентификации на странице входа (взаимодействие через Интернет и сервер), после успешной аутентификации cas-сервер генерирует TGT, а затем использует TGT для генерации ST.
Затем перенаправьте в третий раз и верните ST и cookie (TGC) в браузер.
Браузер использует ST для посещения адреса, который вы хотите посетить.
После того, как сервер браузера получит СТ, зайдите на cas-сервер, чтобы проверить, выдан ли он для себя
Затем войдите на другой веб-сайт, который обращается к CAS, перенаправьте на сервер CAS, сервер считает, что это первый раз (но в это время есть TGC, который является файлом cookie, поэтому нет необходимости переходить на страницу входа)
Но в настоящее время нет ST, перейдите на cas-server, чтобы подать заявку на него, а затем перенаправьте на cas-server.
cas-сервер сгенерировал ST через TGT + TGC
После того, как сервер браузера получит СТ, зайдите на cas-сервер, чтобы проверить, выдан ли он для себя

Я знаю, что большинству людей лень смотреть на это, и мне тоже, поэтому я нарисовал картинку!!!

2.3.3 CAS FAQ

Самые большие различия между CAS и OAuth:

CAS и OAuth являются структурой/протоколом аутентификации, тогда как Token/ST является формой билета, и нет конкретной атрибуции.

1 Ресурсы и информация для пользователей:
- Прежде всего, должно быть ясно, что это не одно и то же!
- Ресурсы защищены и доступны только после успешной аутентификации.Обычно ресурсы CAS существуют на стороне клиента, а ресурсы OAuth существуют на стороне сервера.
- Информация о пользователе находится в системе аутентификации при входе в систему и возвращается после успешной аутентификации, и она существует явно или неявно на сервере.
2 Незначительные отличия в процессе подачи заявки:
- Когда CAS завершает вторичную аутентификацию (уже вошел в систему), он может напрямую использовать ST для аутентификации.Одна из причин этого заключается в том, что он распознает сеанс и токен в
- Когда OAuth выполняет аутентификацию, в дополнение к временному коду (Code) также требуется ClientSecret, чтобы определить, является ли клиент законным или нет.
3 клиента:
- Исходя из предыдущего пункта, CAS кажется, что клиент в принципе один и тот же, не смотря ни на что, просто в куки закинул TGC
- Хотя клиент OAuth — это то же самое в бизнесе, обработка удостоверений клиента выполняется искусственно.

Сертификат CAS:

CAS записывает TGC в файл cookie, когда следующая аутентификация должна удалить аутентификацию TGC из файла cookie,Так что, если вы хотите войти в систему через браузер, вы можете сделать статью здесь!

Суммировать

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

Ссылка и спасибо

Справедливости ради, их довольно много, но я не запомнила адрес, когда вспомнила, так что мне лень его искать, так что желаю всем здоровья.