Привет всем, я Чен Хаха. Появление единого входа в систему призвано решить проблемы, с которыми сталкиваются многие предприятия. Сценарий таков: пользователям необходимо входить в N программ или систем, и каждая программа и система имеют разные имя пользователя и пароль. На ранних стадиях бизнеса, когда программ может быть всего несколько, управление учетными записями и паролями не является сложной задачей. Но когда приложений десятки, сотни или тысячи, даже «Тысячерукая Гуаньинь» крайне сложна. Ведь мозг не многопоточен.   Эта статья начнется с унифицированного СертификациясерединаизАутентификация и авторизация、SSOЕдиный вход、четыре вида Безопасность Сертификацияпротокол、Сравнение четырех сертификатов протоколаПоговорим о нескольких аспектах,Я надеюсь, что вы получили товар.

Представленный материал：Кот из богатой семьи автор：Эр Нин

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

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

🍓Аутентификация (кто я?)

Пример: покажите курьеру свое удостоверение личности, чтобы доказать, что вы — это вы, и он доставит вам курьера.

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

🍓Авторизация Авторизация (что я могу сделать?）

Пример: вы показали курьеру свое удостоверение личности, а затем дали ему пароль от двери вашей комнаты и сказали: «Я дам вам пароль от двери, и вы можете положить его для меня в моей гостиной».

  Авторизация означает, что вам разрешен доступ к определенной области приложения или выполнение определенного действия. Разрешение основано на определенных стандартах и ​​условиях приложения. Это также называется контролем доступа или контролем разрешений.

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

2. Единая аутентификация — единый вход

 Полное английское название системы единого входа — Single Sign On или сокращенно SSO. Его определение таково: в системах с несколькими приложениями пользователям достаточно войти в систему только один раз, чтобы получить доступ ко всем взаимно доверенным системам приложений. Служба единого входа используется для решения проблемы аутентификации личности между различными бизнес-приложениями одной компании. Вам нужно всего лишь один раз войти в систему, чтобы получить доступ ко всем добавленным приложениям.

Основные решения технологии единого входа (протоколы аутентификации безопасности) включают пять типов:

• JWTЕдиный входпротокол
• OpenID Connect (OIDC) Единый входпротокол
• OAuth 2.0Единый входпротокол
• SAML Единый входпротокол
• CAS Единый входпротокол

🍓Протокол JWT

Веб-токен Json (JWT) — это краткая спецификация декларативного объявления для передачи информации безопасности между двумя сторонами. В качестве открытого стандарта (RFC 7519) JWT определяет краткий метод безопасной передачи информации в виде объектов Json между взаимодействующими сторонами. Токен спроектирован так, чтобы быть компактным и безопасным, особенно подходящим для распределенных сайтов с единым входом (SSO). ) сценарий.

🍋Преимущества JWT

• Малый размер (нитка). Таким образом, скорость передачи высокая;
• Существуют различные способы передачи. Может передаваться через HTTP-заголовок (рекомендуется)/URL/POST-параметры и т. д.;
• Строгая структура. Он сам (в полезных данных) содержит все сообщения проверки, связанные с пользователем, такие как доступные пользователю маршруты, период действия доступа и т. д. Серверу не требуется подключаться к базе данных для проверки достоверности информации, а полезная нагрузка поддерживает настройка приложения;
• Поддержка междоменной проверки. Чаще всего используется в Единый вход;

🍋Протокол JWT — Состав токена

Состав токена (xxxx.yyyy.zzzz):

• Header
• Payload
• Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VybmFtZSI6InRlc3QiLCJpYXQiOjE1OTM5NTU5NDMsInVpZCI6MTAsImV4cCI6MTU5Mzk1NTk3Mywic2NvcGVzIjpbImFkbWluIiwidXNlciJdfQ.
VHpxmxKVKpsn2Iytqc_6Z1U1NtiX3EgVki4PmA-J3Pg

🍋Протокол JWT — заголовок

 Заголовок обычно состоит из двух частей: типа токена (например, JWT) и используемого алгоритма подписи (например, HMAC SHA256 или RSA). Например:

{
    "alg": "SHA256",
    "typ": "JWT"
}

Заголовок будет иметь формат Base64Url, закодированный как первая часть JWT. То есть:

$ echo  -n '{"alg":"HS256","typ":"JWT"}'|base64

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

🍋Протокол JWT — полезная нагрузка

Это предопределенный набор утверждений, которые не являются обязательными, но рекомендуются для обеспечения полезного набора совместимых утверждений. Вот некоторые из них: iss (эмитент JWT), exp (срок действия, время истечения срока действия), sub (субъект), aud (получатель JWT), iat (выдано, время выдачи), nbf (недоступно ранее), jti ( идентификатор JWT используется для идентификации JWT) и т. д.

{ "iat": 1593955943, 
  "exp": 1593955973, 
  "uid": 10, 
  "username": "test", 
  "scopes": [ "admin", "user" ] 
}

Полезная нагрузка будет иметь формат Base64Url, закодированный как вторая часть JWT. То есть:

$ echo -n '{"iat":1593955943,"exp":1593955973,"uid":10,"username":"test","scopes":["admin","user"]}'|base64

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

eyJ1c2VybmFtZSI6InRlc3QiLCJpYXQiOjE1OTM5NTU5NDMsInVpZCI6MTAsImV4cCI6MTU5Mzk1NTk3Mywic2NvcGVzIjpbImFkbWluIiwidXNlciJdfQ

🍋Протокол JWT — подпись

Для генерации части подписи требуется заголовок в кодировке Base64, полезная нагрузка в кодировке Base64, ключ (секрет), а в заголовке необходимо указать алгоритм подписи.

Signature：

HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VybmFtZSI6InRlc3QiLCJpYXQiOjE1OTM5NTU5NDMsInVpZCI6MTAsImV4cCI6MTU5Mzk1NTk3Mywic2NvcGVzIjpbImFkbWluIiwidXNlciJdfQ.
VHpxmxKVKpsn2Iytqc_6Z1U1NtiX3EgVki4PmA-J3Pg

🍓Протокол OAuth2

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

🍋Протокол OAuth2 — сценарий применения

• Встроенная авторизация приложения: приложение Авторизоваться запрашивает фоновый интерфейс.,для Безопасность Сертификация,Все запросы содержат информацию о токене.,если Авторизоватьсяпроверять、 Запросить исходные данные.
• Одностраничное приложение с разделением внешнего и внутреннего интерфейса: структура разделения внешнего и внешнего интерфейса,Интерфейсный интерфейс запрашивает фоновые данные,oauth2Безопасность требуется аутентификация.
• Авторизация сторонних приложений Авторизоваться,Такие как QQ,Вейбо,Вичатиз Авторизовать Авторизоваться。

🍋Протокол OAuth2 — возможности протокола

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

🍋Протокол OAuth2 — режим авторизации

 Клиент должен получить авторизацию пользователя (предоставление авторизации) для получения токена (токена доступа). OAuth 2.0 разделен на четыре типа авторизации (предоставление авторизации).

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

  Чаще используются режим кода авторизации и режим пароля.

 Прежде чем сторонние приложения подадут заявку на получение токенов, они должны сначала зарегистрироваться в системе и объяснить свою личность, после чего они получат два идентификационных кода: идентификатор клиента (client ID) и секрет клиента (client secret). Это необходимо для предотвращения злоупотребления токеном. Незарегистрированные сторонние приложения не получат токен.

🍓Протокол OpenID Connect

OpenID Connect, называемый OIDC, представляет собой протокол, расширенный на основе OAuth2.0. Он создает уровень идентификации на основе OAuth2 для аутентификации и представляет собой стандартный протокол аутентификации личности, основанный на протоколе OAuth2. Можно сказать, что протокол OIDC на сегодняшний день является самым популярным протоколом.

OAuth2 фактически выполняет только авторизацию, а OpenID Connect добавляет аутентификацию поверх авторизации.

Преимущества OIDC: простой токен идентификации на основе JSON (JWT) и полная совместимость с протоколом OAuth2.

OpenID(Аутентификация)+ OAuth 2.0 (авторизация)= OpenID Подключиться (аутентификация + авторизация)

Процесс авторизации входа в протокол OIDC в ​​основном аналогичен процессу OAuth2.0, и участники всего процесса также аналогичны. По сравнению с OAuth2, OIDC вводит id_token и другие концепции, связанные с информацией о пользователе:

• Весь протокол OAuth2,Только да определяет access_token/refresh_token,нода Эти двоеtokenТолькодадля ЗащищатьResource Сервер, нет Ресурса идентификационные данные владельца;
• OIDC представил концепцию id_token, используя этот специальный токен для обозначения того, что это удостоверение личности владельца ресурса;
• Стандартизированный формат id_token: хорошо известный JWT;
• Стандартизируйте содержимое id_token: стандартные утверждения
• OIDC представил конечную точку для получения подробной информации о пользователе;

🍋Протокол OpenID Connect — значение IDToken

1. Добавление идентификационной информации пользователя в токен доступа может привести к утечке информации пользователя;

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

1. Целью токена доступа является предоставление учетных данных для доступа к интерфейсу. Если он также содержит информацию о пользователе, функции не будут разделены.
2. Используйте idToken для замены конечной точки userinfo, чтобы получить информацию о пользователе и сократить накладные расходы на запросы;

  Обычно протокол oauth2 предоставляет информацию о пользователе. endpointПолучить информацию о пользователе,Пример Microsoft：https://graph.microsoft.com/oidc/userinfo,использоватьaccess токен вызывает этот интерфейс для получения информации о пользователе; idToken может сохранить вызов userinfo; Дополнительное использование интерфейса API;

1. некоторые сцены,Если вам нужно только авторизоваться пользователя для аутентификации и получения информации о пользователе,Не нужно звонить в Ресурс Другие API-интерфейсы сервера; тогда в этом сценарии необходимо вернуть только idToken, а accessToken не нужно возвращать;

  С точки зрения объема полномочий：OAuth2 > OpenID Connect。

 Многие веб-сайты теперь предоставляют «Использовать быструю аутентификацию WeChat» (также известную как OAuth2) в качестве метода входа. Но это может быть опасно, если вы не уверены, заслуживает ли сайт доверия. Потому что после того, как OAuth2 авторизует вход в систему, это эквивалентно передаче некоторых ваших данных WeChat (таких как имя, изображение, номер мобильного телефона) и прав (например, отправка личных сообщений) на этот веб-сайт. делай, ты понятия не имеешь.

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

🍓SAML-протокол

SAML — это аббревиатура языка разметки утверждений безопасности. Это открытый стандартный протокол, основанный на XML, используемый для обмена данными аутентификации и авторизации между поставщиком удостоверений (сокращенно поставщик удостоверений) и поставщиком услуг (сокращенно поставщик услуг).

• IDP: поставщик услуг аутентификации учетной записи (унифицированная аутентификация).
• SP: Предоставление коммерческих услуг программного обеспечения (субъекта) пользователям, таких как подсистема полного резервирования.
• Пользовательский агент: веб-браузер

1. Пользователь попробовал Авторизоваться SP Приложения предоставлены.
2. Поставщик услуг генерирует запрос SAML и отправляет запрос SAML IdP посредством перенаправления браузера.
3. IdP анализирует запрос SAML и перенаправляет пользователя на страницу аутентификации.
4. Пользователь завершает авторизацию на странице аутентификации.
5. IdP генерирует ответ SAML и возвращает ответ SAML на адрес ACS поставщика услуг, перенаправляя браузер, который содержит утверждение SAML, используемое для определения личности пользователя.
6. Поставщик услуг проверяет содержимое ответа SAML.
7. Успех пользователя Авторизоватьсяприезжать SP Приложения предоставлены.

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

Если на первом этапе поставщик услуг не найдет соответствующую действительную информацию аутентификации в браузере, он сгенерирует соответствующий запрос SAMLRequest и перенаправит агента пользователя к IdP.

🍋Протокол SAML — Параметры

🍋Протокол SAML – недостатки SAML

• Протоколизация сложна: документ SAML по протоколизации больше,Пользователям может потребоваться больше времени, чтобы понять протокол,Будьте знакомы с ним и как его использовать.
• Высокие затраты на внедрение: для SAML требуется серверное программное обеспечение, которое активно поддерживает язык разметки утверждений безопасности (SAML), а установка и настройка этого серверного программного обеспечения может быть дорогостоящей.
• Плохая совместимость в мобильном приложении: SAML требует HTTP. Редект и HTTP POST используется для передачи информации о пользователе, а данные обычно передаются через формат FORM.

🍓CAS-протокол

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

• CAS-сервер должен быть развернут независимо и в основном отвечает за аутентификацию пользователей;
• CAS Клиент несет ответственность за обработку запросов доступа к защищенным ресурсам клиента. Если требуется Авторизация, перенаправьте в CAS. Server。

🍋Протокол CAS – процесс сертификации:

1. Система доступа пользователей к приложениям,Система приложения требует аутентификации пользователя,Затем перенаправьте на сервер CAS;
2. Пользователь вводит имя пользователя и пароль на сервере CAS, а сервер CAS проверяет учетную запись пользователя и пароль;
3. После успешной проверки,CAS-сервер привязан к билету,и перенаправить обратно в систему приложения;
4. Примените систему и отправьте билет на CAS-сервер для проверки.,После успешной проверки,Сервер CAS возвращает действующую учетную запись пользователя (может быть имя пользователя, адрес электронной почты и т. д.);
5. Система приложения использует возвращаемую учетную запись пользователя для локальной аутентификации пользователя.,После успешной аутентификации,Пользователи могут авторизовать систему приложений.

🍋Соглашение CAS – Процесс авторизации:

1. После того, как пользователь Авторизируется применит систему, ему необходимо получить доступ к определенному ресурсу;
2. Прикладная система отправляет запрос доступа пользователя на сервер CAS и переносит идентификационную информацию пользователя;
3. Сервер CAS проверяет идентификационную информацию пользователя и определяет, имеет ли пользователь право доступа к ресурсу на основе разрешений пользователя;
4. CAS-сервер возвращает результат авторизации приложению;
5. Система приложения возвращает результат авторизации по данным CAS-сервера.,Определяет, разрешен ли пользователю доступ к ресурсу.

Пользователи получают доступ к сервисам на разных языках и с разными архитектурами, и сервисы взаимодействуют с сервером аутентификации через такие протоколы, как CAS, SAML и Oauth. Сервер аутентификации, основанный на платформе Spring MVC, получает данные из LDAP, базы данных или AD для аутентификации. пользователя, а затем аутентифицирует пользователя. Пользователь выдает учетные данные.

 Текущая версия CAS объединяет механизмы аутентификации, такие как AD, Generic, LDAP, JDBC и т. д. В связи с потребностями разработки текущая версия CAS уже поддерживает некоторые другие протоколы идентификации, такие как OIDC, Oauth 2.0 и т. д.

3. Сравнение четырех протоколов аутентификации.

 Проведите конкретное сравнение четырех стандартных протоколов аутентификации: OIDC, OAuth 2.0, SAML2 и CAS 3.0: