What does SSO stand for, and what problem does it solve?

SSO stands for Single Sign-On. It is an authentication pattern that lets a user sign in once with their corporate identity provider and then access multiple downstream applications — including SecureCodingHub — without re-entering credentials. The point is not just convenience; it lets your security team enforce password policy, MFA, and offboarding in one place rather than per-application.

SSO vs SAML — are they the same thing?

No. SSO is the user-facing pattern; SAML is one of the protocols that can implement it. When you compare SSO vs SAML, the cleaner framing is that SAML 2.0 is a federation standard that carries the authentication assertion from your identity provider to the application, and SecureCodingHub speaks it. OIDC (built on OAuth 2.0) is the modern alternative for the same SSO outcome.

SSO vs OAuth — what is the actual difference?

The SSO vs OAuth distinction trips people up because OIDC sits on top of OAuth 2.0. OAuth 2.0 by itself is an authorization framework — it grants an application access to a resource. OIDC adds an identity layer on top, which is what makes OAuth-based SSO possible. So OAuth 2.0 alone does not give you SSO; OIDC over OAuth 2.0 does.

Can I use SSO with an open source identity provider?

Yes. Because SecureCodingHub supports the open standards — SAML 2.0 and OIDC — any open source SSO identity provider that implements them works. Keycloak, Authentik, and Zitadel are common picks for teams that want to self-host the IdP. The configuration steps on the SecureCodingHub side are identical to those for Azure AD or Okta; you supply the metadata or discovery URL and map the attributes.

Обзор SSO

SecureCodingHub поддерживает единый вход через OpenID Connect (OIDC) и SAML 2.0. SSO позволяет Вашей команде входить с их корпоративным поставщиком идентификации — отдельные пароли не нужны.

Поддерживаемые протоколы

SecureCodingHub поддерживает два отраслевых стандарта SSO-протоколов:

OIDC (OpenID Connect)

Современный протокол на основе OAuth 2.0. Рекомендуется для Azure AD, Okta и большинства облачных поставщиков идентификации. Использует поток кода авторизации с PKCE.

SAML 2.0

XML-протокол федерации. Поддерживается для устаревших поставщиков идентификации и корпоративных сред.

Как работает SSO

Когда SSO настроен для Вашей организации, поток входа работает следующим образом:

Пользователь переходит к входу SecureCodingHub

Попадает на точку входа SSO для своей организации (ссылка несёт org slug; сегодня нет автоматического определения email-домена)

Браузер перенаправляет к Вашему поставщику идентификации (Azure AD, Okta и т.д.)

Пользователь аутентифицируется с корпоративными учётными данными

IdP перенаправляет обратно в SecureCodingHub с auth-токеном

SecureCodingHub создаёт сессию и выполняет вход пользователя

JIT-провижининг

Когда SSO включён, пользователи автоматически создаются при первом входе — это называется Just-In-Time (JIT) провижининг. Новым пользователям по умолчанию назначается роль Учащийся. У Вашей организации должны быть доступные места, чтобы новые пользователи были созданы.

URL конфигурации

Используйте следующие URL при настройке Вашего поставщика идентификации:

Настройка	Значение
OIDC Callback URL	`https://api.limeplate.com/api/sch/auth/sso/callback/oidc`
SAML ACS URL	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
SP Metadata URL	`https://api.limeplate.com/api/sch/auth/sso/metadata`

Примечание: Настройка SSO требует доступа Администратор организации или Platform Admin. См. руководства по настройке Azure AD или Okta, чтобы начать.

Выбор между SAML и OIDC

Если Ваш поставщик идентификации поддерживает оба протокола, практический ответ — выбрать то, что Ваша команда безопасности уже эксплуатирует и которому доверяет. OIDC — это более новый JSON-протокол, построенный на OAuth 2.0. С ним удобнее разрабатывать, легче отлаживать, и это вариант по умолчанию в большинстве современных IdP, включая Azure AD и Okta. Для организаций, стандартизирующих cloud-native инструменты, OIDC обычно правильный выбор.

SAML — это более старый XML-стандарт федерации, и он остаётся самым распространённым выбором в корпоративных средах. Причина редко в технических предпочтениях. Дело в том, что команда IdP уже запускает десятки SAML-интеграций, календарь ротации сертификатов установлен, а внутренний playbook для устранения неполадок SAML зрелый. Если Вы развёртываете в среде с PingFederate, ADFS или устаревшим SAML IdP, выбор SAML позволяет переиспользовать существующие шаблоны вместо того, чтобы просить команду IdP поддержать разовую OIDC-интеграцию. Оба протокола обеспечивают эквивалентную безопасность; выбор о операционной совместимости, а не о криптографии.

Чек-лист перед SSO

Прежде чем Вы включите SSO в продакшене, спланируйте вокруг трёх реальностей. Во-первых, настройте тестовую среду или используйте тенант, который Вы контролируете от начала до конца. Неправильно настроенный SSO может заблокировать всех, включая администратора, который его настроил. Запустите полный поток входа против некритичной организации сначала, идеально с одноразовым приложением IdP, чтобы Вы могли итерировать по сопоставлению атрибутов без срочности. Во-вторых, держите как минимум одну запасную admin-учётную запись, не зависящую от SSO. SecureCodingHub чтит break-glass локальный admin-путь, и время для его тестирования — до того, как SSO выйдет в эксплуатацию, а не в 9 вечера в пятницу, когда что-то пошло не так.

В-третьих, продумайте downstream-влияние на потоки приглашений по email. Как только SSO активен, пользователи из Вашего верифицированного домена перенаправляются к IdP и JIT-провизионятся при первом входе. Это означает, что администратор, вручную приглашающий пользователей по email, и администратор каталога, назначающий приложение в IdP, оба могут создавать учётные записи, и два потока столкнутся, если Вы не выберете один. Чище — отключить ручные приглашения для SSO-управляемого домена и сделать IdP единственным источником истины. См. Руководство по настройке SAML и руководства по конкретным протоколам для следующего шага.

SSO: часто задаваемые вопросы

Что означает SSO и какую проблему решает?

SSO означает Single Sign-On (единый вход). Это шаблон аутентификации, позволяющий пользователю войти один раз со своим корпоративным поставщиком идентификации и затем получить доступ к нескольким downstream-приложениям — включая SecureCodingHub — без повторного ввода учётных данных. Смысл не только в удобстве; это позволяет Вашей команде безопасности навязывать парольную политику, MFA и оффбординг в одном месте, а не на приложение.

SSO vs SAML — это одно и то же?

Нет. SSO — это пользовательский шаблон; SAML — один из протоколов, которые могут его реализовать. Когда Вы сравниваете SSO vs SAML, более чистое обрамление в том, что SAML 2.0 — это стандарт федерации, передающий аутентификационное утверждение от Вашего поставщика идентификации к приложению, и SecureCodingHub говорит на нём. OIDC (построенный на OAuth 2.0) — это современная альтернатива для того же результата SSO.

SSO vs OAuth — в чём фактическая разница?

Различие SSO vs OAuth путает людей, потому что OIDC сидит поверх OAuth 2.0. OAuth 2.0 сам по себе — это фреймворк авторизации — он предоставляет приложению доступ к ресурсу. OIDC добавляет слой идентификации сверху, что и делает OAuth-based SSO возможным. Так что OAuth 2.0 один не даёт Вам SSO; OIDC поверх OAuth 2.0 даёт.

Могу ли я использовать SSO с open source поставщиком идентификации?

Да. Поскольку SecureCodingHub поддерживает открытые стандарты — SAML 2.0 и OIDC — любой open source SSO-поставщик идентификации, реализующий их, работает. Keycloak, Authentik и Zitadel — распространённые выборы для команд, желающих self-host'ить IdP. Шаги конфигурации на стороне SecureCodingHub идентичны тем, что для Azure AD или Okta; Вы поставляете URL метаданных или discovery и сопоставляете атрибуты.