При проектировании системы большинству из них требуется схема авторизации входа для обеспечения безопасности доступа и контроля разрешений. К счастью, у нас есть такие фреймворки, как Spring, которые чаще всего требуют для работы всего несколько строк конфигурации. Это также заставляет разработчика игнорировать свой рабочий процесс и принципы, поэтому давайте разберемся и обсудим в этой статье. Сначала бросьте концепцию: единый вход SSO (Single Sign On).
SSO&CAS
Он определяется как:
SSO заключается в том, что в системах с несколькими приложениями пользователям необходимо войти в систему только один раз, чтобы получить доступ ко всем взаимно доверенным системам приложений. Он включает механизмы для сопоставления этого основного входа в систему с именами входа того же пользователя в других приложениях. Это одно из самых популярных решений для корпоративной бизнес-интеграции.
SSO — это концептуальная схема, воплощением которой является знаменитая система CAS Йельского университета, о которой мы часто слышим. В частности, вы можете узнатьCAS Architecture, а его инженерная блок-схема выглядит следующим образом:
Основное, что необходимо решить, - это ввести процесс аутентификации и аутентификации.Для достижения единого доступа к нескольким системам необходима одна и та же схема авторизации.
Аутентификация и аутентификация
Аутентификация (Authentication) и авторизация (Authorization) всегда появляются парами, но их не следует путать.
Проще говоря, аутентификация используется, чтобы определить, является ли Сяо Мин настоящим Сяо Мином. Авторизация предназначена для ограничения разрешений, которые имеет Сяомин.Например, Сяомин может только читать этот блог и не может изменять этот блог, а мой автор может.
Так каким же должен быть этот процесс?План каждой семьи не может быть всегда разным.Тогда есть такой стандарт:OAuth, теперь это до 2.0, что мы хотим знать сегодняOAuth 2.0.так
OAuth2.0 — это стандартный отраслевой протокол авторизации (аутентификации).
OAuth 2.0 ориентирован на простоту для разработчиков на стороне клиента, предоставляя специализированные потоки проверки подлинности для веб-приложений, настольных приложений, мобильных устройств и устройств в жилых комнатах.
Взгляните на официальное описание рабочего процесса:
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Поток абстрактного протокола, ну, это довольно абстрактно, тем более, как делается Предоставление авторизации, пока неизвестно. Но мы можем знатьЧтобы получить доступ к службе ресурсов, мы, наконец, получаем токен доступа, назначенный службой авторизации., Существует несколько режимов авторизации OAuth 2.0, в основном в соответствии с требованиями дизайна. Возьмем для анализа один из самых сложных и полных паттернов: паттерн кода авторизации. Точно так же давайте сначала посмотрим на официальное объяснение:
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
На рисунке мы можем видеть общий процесс.Когда пользователи получают доступ к ресурсам, они должны быть сначала авторизованы службой авторизации.В процессе доступа к службе авторизации пользователь вводит зарегистрированный Clent ID и перенаправленный адрес через клиентского агента, и служба авторизации проверена.Если это правильно, код авторизации будет передан агенту клиента, и код авторизации будет доведен до клиента.Клиент может получить доступный токен доступа с помощью этого кода авторизации. Как упоминалось выше, только получив действительный токен доступа, мы можем получить беспрепятственный доступ к нашим службам ресурсов.
Но... почему это так сложно? Почему бы не получить токен доступа при первом доступе к службе авторизации (аутентификация пользователя), но вам нужно получить токен доступа через код авторизации?
Ответ: для безопасности
Во-первых, ситуация, когда требуется такой код авторизации, только устанавливается, поэтому Https для доступа не используется, а блогеры, похожие на бедных иксов, не могут позволить себе услуги ssl-аутентификации. Поскольку проблема может быть связана со способом предоставления токена доступа клиенту, если AccessToken возвращается напрямую посредством перенаправления, это дает хакеру возможность захватить токен доступа, поскольку uri может быть передан другим вредоносным сайтам. через реферер HTTP, а также может существовать в кеше браузера или файлах журнала. Однако прямое перенаправление обратно к коду авторизации не является конфиденциальными данными. При повторной проверке кода авторизации для получения токена доступа необходимо загрузить ключ клиента (имеется только у клиента). Доступ возможен только при наличии действительного секрета клиента. быть гарантировано безопасным.
Если вы не бедный человек, как блогер, официальная рекомендация также — режим неявного потока, который быстрее и безопаснее.
Выше процесс OAuth2 в основном ясен. Так получилось, что у трудолюбивого бога также есть несколько хороших кодов реализации для справки. Вот хороший пример реализации:oltu-oauth2-example
Нарисуйте блок-схему вместе, чтобы помочь понять:
Список важных процессов
- Зарегистрируйте приложение: получите client_id, client_secret.
- Запросить код авторизации: получить код авторизации auth_code через client_id
- В обмен на accessToken: Получить AccessToken через client_id, client_secret, auth_code
- Доступ к службам ресурсов через AccessToken
В процессе запроса авторизации необходимо открыть страницу входа, ввести правильное имя пользователя и пароль, а затем вернуться к auth_code.