Предисловие

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

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

OAuth — это не SSO,Хотя разработчики часто путают эти два понятия.

Большая часть путаницы связана с тем, что поставщики OAuth, такие как Google, позволяют пользователям входить в несколько приложений, используя свою учетную запись, поскольку SSO делает то же самое.

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

В этой статье мы объясним различия между OAuth и SSO и поможем вам решить, какой из них вам следует использовать.

1. Введение концепции

1.1 SSO: единый вход

• SSO (единый вход, единый вход)

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

Как показано на рисунке, SSO — это модуль, который извлекает данные входа в систему. App1 и App2 отвечают только за модуль приложения, а SSO отвечает только за модуль входа. Когда App1 и App2 необходимо войти в систему, они перейдут в систему единого входа. После того как система единого входа завершит вход, другие системы приложений также войдут в систему.

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

1.2 OAuth: открытая авторизация

• OAuth (Открытая авторизация, открытая авторизация)

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

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

2. Технические принципы SSO

2.1 Основные компоненты единого входа

• Центральный сервер аутентификации

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

• Билетный механизм

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

• Проверка системы приложения

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

2.2 Принцип реализации

Принцип реализации SSO показан на рисунке ниже:

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

2.3 Сценарии применения единого входа

• Внутренняя интеграция приложений

Для крупных предприятий существует множество внутренних прикладных систем, таких как ERP, CRM, HR и т. д. Внедрив единый вход, вы можете значительно повысить производительность сотрудников и сократить перерывы в работе, вызванные проблемами управления паролями.

• Междоменный федеративный вход

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

• Интеграция облачных сервисов

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

3. Технические принципы OAuth

3.1 Процесс авторизации OAuth

• Разделение ролей:OAuth Здесь задействованы три основные роли, а именно владелец ресурса (обычно пользователь), сервер ресурсов (сервер, на котором хранятся ресурсы пользователя) и клиентское приложение (стороннее приложение, которое хочет получить доступ к ресурсам пользователя).
• Процесс авторизации：
  • Пользователь сначала обращается к клиентскому приложению, и клиентское приложение запрашивает у пользователя авторизацию для доступа к определенным ресурсам на сервере ресурсов;
  • После того как пользователь согласится на авторизацию, клиентское приложение перенаправит пользователя на страницу авторизации сервера ресурса;
  • Пользователь подтверждает авторизацию на странице авторизации, а сервер ресурсов сгенерирует код авторизации (Authorization Code) и вернет его клиентскому приложению;
  • Клиентское приложение использует код авторизации для обмена токеном доступа (Access Token) с сервером ресурсов;
  • Клиентское приложение использует токен доступа для запроса доступа к ресурсам пользователя с сервера ресурсов.

3.2 OAuth 2.0

Последней версией является OAuth версии 2.0, которая в основном состоит из четырех субъектов:

• Сервер авторизации отвечает за выдачу токенов доступа (Access Token — это сервер авторизации).
• Владелец ресурса. Пользователь приложения является владельцем ресурса и разрешает другим пользователям доступ к его ресурсам.
• Вызывающая сторона запрашивает получение токена доступа (Access Token). После того, как пользователь авторизует его, Authing выдает ему токен доступа (Access Token). Вызывающая сторона может передать токен доступа на сервер ресурсов для доступа к ресурсам пользователя.
• Сервер ресурсов принимает токен доступа, затем проверяет назначенные ему разрешения и, наконец, возвращает ресурс.

3.3 Режим авторизации OAuth 2.0

OAuth 2.0 имеет четыре режима авторизации:

1. Код авторизации: относится к стороннему приложению, которое сначала запрашивает код авторизации, а затем использует этот код для получения токена. Этот метод является наиболее часто используемым процессом и имеет самый высокий уровень безопасности. Он подходит для веб-приложений с серверной частью.
2. Неявный: этот режим предназначен для чисто интерфейсных приложений, и сервер аутентификации приложений возвращает код авторизации только один раз.
3. Пароль: позволяет клиентам или сторонним приложениям напрямую использовать учетную запись и пароль пользователя для получения токенов. Этот метод широко используется на стороне пользователя.
4. Учетные данные клиента: подходят для приложений командной строки без внешнего интерфейса, то есть запрашивающих токены из командной строки. Этот метод прост в использовании. Вам нужно всего лишь отправить клиентский запрос для получения токена доступа (Access Token). Однако этот метод очень небезопасен и требует полного доверия к клиенту, а сам клиент должен быть защищен.

3.4 Сценарии применения OAuth

• Авторизация сторонних приложений

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

• Открытый API платформы социальных сетей

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

• Авторизация в мобильном приложении

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

4. Преимущества и проблемы

4.1 Преимущества и проблемы единого входа

Преимущества единого входа

• Улучшите взаимодействие с пользователем: пользователям нужно запомнить только одно имя пользователя и пароль для доступа к нескольким системам приложений, что снижает нагрузку, связанную с запоминанием нескольких паролей и обременительными операциями входа в систему.
• Повышенная безопасность: централизованное управление авторизацией аутентификации может лучше обеспечить безопасность личных данных пользователей. Центральный сервер аутентификации может применять более строгие политики безопасности, такие как многофакторная аутентификация, усиление политики паролей и т. д.
• Упрощенное управление: для предприятий IT Для администраторов, SSO Может упростить управление учетными записями пользователей. Просто Центральный сервер После создания, изменения или удаления учетной записи пользователя посредством аутентификации ее можно синхронизировать со всеми связанными прикладными системами.

Однако SSO также сталкивается с некоторыми проблемами:

• Риск единой точки отказа: если Центральный сервер аутентификациинеисправность,Это приведет к тому, что все прикладные системы, которые полагаются на него, не смогут работать.,Воздействие велико.
• Проблемы совместимости. Различные прикладные системы могут использовать разные технические архитектуры и протоколы, поэтому проблемы совместимости между этими системами необходимо решать при реализации единого входа.
• Концентрация рисков безопасности: из-за Центрального сервер аутентификации Хранит большое количество идентификационной информации пользователя.,однажды напали,Может привести к масштабной утечке информации.

4.2 Преимущества и проблемы OAuth

Преимущества OAuth:

• Высокая безопасность ресурсов: пользователям не нужно сообщать свои пароли сторонним приложениям, что снижает риск утечки паролей. Даже если стороннее приложение подвергнется атаке, это не повлияет на безопасность пароля пользователя на сервере ресурсов.
• Гибкий контроль авторизации: пользователи могут выбирать, к каким ресурсам и уровням разрешений разрешать доступ сторонним приложениям в соответствии со своими потребностями, что является очень гибким.
• Содействие развитию экосистемы приложений: OAuth обеспечивает удобство разработки сторонних приложений, способствует появлению различных инновационных приложений и обогащает экосистему приложений Интернета.

У OAuth также есть некоторые проблемы:

• Понимание пользователя и сложность работы: для обычных пользователей OAuth 的Процесс авторизация может быть относительно сложной и требует определенного понимания и оперативных возможностей. Некоторые пользователи могут, потому что что Не понимает значения авторизации и авторизует ее по своему желанию, что приводит к потенциальным угрозам безопасности.
• Риск злоупотребления авторизацией. Хотя пользователи могут контролировать объем авторизации, некоторые некачественные сторонние приложения могут обманывать или побуждать пользователей к чрезмерной авторизации, тем самым получая больше информации о пользователе.
• Техническая сложность реализации: Для разработчиков реализация OAuth Процесс авторизации Требуется несколько шагов для обработкиивзаимодействие,Использование сложных технических операций, таких как шифрование и управление токенами.,Увеличивает сложность и стоимость разработки.

5. Будущие тенденции развития

5.1 Тенденции развития SSO

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

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

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

5.2 Тенденции развития OAuth

Более тонкая детализация авторизации. Чтобы лучше защитить пользовательские ресурсы, OAuth будет развиваться в направлении более тонкой детализации авторизации, позволяя пользователям более точно контролировать доступ к ресурсам, например, по времени, количеству раз, типу операции и т. д. Авторизоваться.

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

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

Подвести итог

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