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.

Descripción general de SSO

SecureCodingHub admite inicio de sesión único mediante OpenID Connect (OIDC) y SAML 2.0. SSO permite que su equipo inicie sesión con su proveedor de identidad corporativo, sin contraseñas separadas.

Protocolos admitidos

SecureCodingHub admite dos protocolos SSO estándar del sector:

OIDC (OpenID Connect)

Protocolo moderno basado en OAuth 2.0. Recomendado para Azure AD, Okta y la mayoría de proveedores de identidad en la nube. Utiliza el flujo de código de autorización con PKCE.

SAML 2.0

Protocolo de federación basado en XML. Compatible con proveedores de identidad heredados y entornos empresariales.

Cómo funciona SSO

Cuando SSO está configurado para su organización, el flujo de inicio de sesión funciona así:

El usuario navega al inicio de sesión de SecureCodingHub

Llega al punto de entrada SSO de su organización (el enlace lleva el slug de la organización; hoy no hay detección automática por dominio de correo)

El navegador redirige a su proveedor de identidad (Azure AD, Okta, etc.)

El usuario se autentica con las credenciales corporativas

El IdP redirige de vuelta a SecureCodingHub con un token de autenticación

SecureCodingHub crea una sesión e inicia la sesión del usuario

Aprovisionamiento JIT

Cuando SSO está activado, los usuarios se crean automáticamente en el primer inicio de sesión — esto se denomina aprovisionamiento Just-In-Time (JIT). Los nuevos usuarios reciben el rol Estudiante por defecto. Su organización debe disponer de asientos libres para que se aprovisionen nuevos usuarios.

URL de configuración

Use las siguientes URL al configurar su proveedor de identidad:

Ajuste	Valor
URL de callback OIDC	`https://api.limeplate.com/api/sch/auth/sso/callback/oidc`
URL ACS de SAML	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
URL de metadatos del SP	`https://api.limeplate.com/api/sch/auth/sso/metadata`

Nota: La configuración de SSO requiere acceso de Administrador de organización o Administrador de plataforma. Consulte las guías de configuración de Azure AD u Okta para empezar.

Elegir entre SAML y OIDC

Si su proveedor de identidad admite ambos protocolos, la respuesta práctica es elegir lo que su equipo de seguridad ya opera y en lo que confía. OIDC es el protocolo más reciente, basado en JSON y construido sobre OAuth 2.0. Es más amigable para desarrollar, más fácil de depurar y la opción por defecto en la mayoría de IdP modernos, incluidos Azure AD y Okta. Para las organizaciones que estandarizan herramientas nativas en la nube, OIDC suele ser la elección correcta.

SAML es el estándar de federación más antiguo, basado en XML, y sigue siendo la opción más habitual en entornos empresariales. La razón rara vez es una preferencia técnica. Es que el equipo del IdP ya gestiona decenas de integraciones SAML, el calendario de rotación de certificados está establecido y el manual interno para solucionar problemas de SAML está maduro. Si está desplegando en un entorno con PingFederate, ADFS o un IdP SAML heredado, elegir SAML le permite reutilizar patrones existentes en lugar de pedir al equipo del IdP que dé soporte a una integración OIDC aislada. Ambos protocolos ofrecen una seguridad equivalente; la elección es sobre encaje operativo, no sobre criptografía.

Lista de verificación previa a SSO

Antes de activar SSO en producción, planifique alrededor de tres realidades. En primer lugar, configure un entorno de prueba o utilice un tenant que controle de extremo a extremo. Un SSO mal configurado puede dejar fuera a todo el mundo, incluido el administrador que lo configuró. Ejecute el flujo completo de inicio de sesión contra una organización no crítica primero, idealmente con una aplicación de IdP desechable, para poder iterar sobre el mapeo de atributos sin urgencia. En segundo lugar, mantenga al menos una cuenta de administrador de respaldo que no dependa de SSO. SecureCodingHub respeta una ruta local de administrador de emergencia, y el momento para probarla es antes de que SSO entre en producción, no a las 9 de la noche del viernes cuando algo ha salido mal.

En tercer lugar, piense en el impacto descendente sobre los flujos de invitación por correo. Una vez activo SSO, los usuarios de su dominio verificado son redirigidos al IdP y aprovisionados mediante JIT en el primer inicio de sesión. Esto significa que un administrador que invita manualmente a usuarios por correo y un administrador de directorio que asigna la aplicación en el IdP pueden ambos crear cuentas, y los dos flujos chocarán si no elige uno. El patrón más limpio es desactivar las invitaciones manuales para el dominio gestionado por SSO y dejar que el IdP sea la única fuente de verdad. Consulte la Guía de configuración de SAML y las guías específicas de cada protocolo para el siguiente paso.

SSO: preguntas frecuentes

¿Qué significa SSO y qué problema resuelve?

SSO significa Single Sign-On (inicio de sesión único). Es un patrón de autenticación que permite a un usuario iniciar sesión una vez con su proveedor de identidad corporativo y, a continuación, acceder a varias aplicaciones — incluida SecureCodingHub — sin volver a introducir credenciales. El objetivo no es solo la comodidad; permite a su equipo de seguridad aplicar la política de contraseñas, MFA y la baja en un único lugar en lugar de hacerlo por aplicación.

SSO vs SAML — ¿son lo mismo?

No. SSO es el patrón orientado al usuario; SAML es uno de los protocolos que pueden implementarlo. Cuando compara SSO frente a SAML, el marco más claro es que SAML 2.0 es un estándar de federación que transporta la afirmación de autenticación desde su proveedor de identidad hasta la aplicación, y SecureCodingHub lo habla. OIDC (construido sobre OAuth 2.0) es la alternativa moderna para el mismo resultado de SSO.

SSO vs OAuth — ¿cuál es la diferencia real?

La distinción SSO frente a OAuth confunde a la gente porque OIDC se asienta sobre OAuth 2.0. OAuth 2.0 por sí mismo es un marco de autorización — concede a una aplicación acceso a un recurso. OIDC añade una capa de identidad encima, que es lo que hace posible el SSO basado en OAuth. Así que OAuth 2.0 por sí solo no le da SSO; OIDC sobre OAuth 2.0 sí.

¿Puedo utilizar SSO con un proveedor de identidad de código abierto?

Sí. Como SecureCodingHub admite los estándares abiertos — SAML 2.0 y OIDC — cualquier proveedor de identidad SSO de código abierto que los implemente funciona. Keycloak, Authentik y Zitadel son elecciones habituales para equipos que quieren autohospedar el IdP. Los pasos de configuración del lado de SecureCodingHub son idénticos a los de Azure AD u Okta; usted suministra la URL de metadatos o de descubrimiento y mapea los atributos.