Auto Secure LoginPlataforma
Menú

Para desarrolladores · Plataforma

Iniciar sesión con Auto Secure Login

Una cuenta en la que sus usuarios ya confían, dentro de su app, con OpenID Connect estándar.

Ofrezca a las personas que usan su app un inicio de sesión que ASL ya protege: contraseña o llave de acceso, verificación en dos pasos y una pantalla de consentimiento que nombra a su app. Usted agrega un botón y una ruta de retorno. ASL se encarga del resto, en inglés y en español.

Lo que obtiene

Iniciar sesión con Auto Secure Login: sin contraseñas que guardar

01

Una cuenta para todas las apps

La persona entra a su app con la misma cuenta de Auto Secure Login que usa en todos los productos ASL y en cualquier otra app que muestre el botón. Una identidad, un solo lugar para administrarla.

02

Verificación en dos pasos incluida

Toda cuenta ASL tiene un segundo paso: un código por correo, un código por mensaje de texto o una llave de acceso. Su app lo hereda en cada inicio de sesión sin programar nada.

03

Consentimiento visible

La primera vez, ASL pregunta a la persona si permite su app, por su nombre, y recuerda la respuesta durante cuatro semanas. No se comparte nada con su app hasta que diga que sí.

04

Llaves de acceso y cuentas de proveedores

Las personas pueden crear su cuenta ASL con contraseña o mediante Google, Microsoft, Apple o GitHub, y entrar con una llave de acceso. Su app ve una sola identidad ASL y nunca habla con esos proveedores.

05

OpenID Connect estándar

Flujo de código de autorización con PKCE, documento de descubrimiento, tokens de identidad firmados con RS256 y un endpoint JWKS. Funciona cualquier biblioteca cliente certificada de OpenID Connect; no hay un SDK que instalar.

06

Inglés y español

Las pantallas de inicio de sesión, verificación en dos pasos y consentimiento se ofrecen en ambos idiomas, igual que esta guía. Las páginas de su app siguen siendo suyas.

Cómo funciona

Cómo funciona el inicio de sesión OpenID Connect para sus usuarios

1. Presiona el botón. Su app la envía al endpoint de autorización de ASL con un state, un nonce y un reto PKCE nuevos. El kit del botón en esta página le da el marcado y la marca.

2. Entra a ASL. Contraseña, llave de acceso o una cuenta vinculada de Google, Microsoft, Apple o GitHub, y luego su verificación en dos pasos. En la primera visita ASL pregunta si permite su app.

3. Vuelve a su app. ASL la regresa a su ruta de retorno con un código. Su servidor lo cambia por un token de identidad firmado y guarda el identificador estable. Ninguna contraseña toca su sistema.

Si ya usa productos ASL en su organización, su gente entra a sus propias herramientas de la misma forma en que entra a todo lo demás. La página de la plataforma explica lo que comparten todos los productos ASL.

10 minduran los tokens de acceso; un token filtrado vive poco
30 díasduran los tokens de actualización con acceso sin conexión
4 semanasse recuerda el consentimiento de la persona a su app
2idiomas en cada pantalla de inicio de sesión de ASL
Marca del escudo de Auto Secure LoginPara quién es. Una app web que quiere un botón de inicio de sesión sin operar su propio sistema de contraseñas y verificación en dos pasos. Una app móvil, de escritorio o de una sola página que no puede guardar un secreto y entra como cliente público con PKCE. Una herramienta hecha para una organización que ya usa productos ASL.

Cómo registrarse

Una persona revisa cada registro; no es un formulario automático

No hay una consola de autoservicio para desarrolladores; una persona revisa cada registro. Escriba a contact@autosecurelogin.com o use el formulario de contacto con tres datos:

  • el nombre de su app y la empresa o persona que la publica;
  • cada URI de redirección, con coincidencia exacta: solo https://, salvo http://localhost para desarrollo;
  • si la app puede guardar un secreto (una app web del lado del servidor) o no (una app móvil, de escritorio o de una sola página, registrada como cliente público que debe usar PKCE).

Usted recibe un ID de cliente que empieza con asl-ext- y, para apps del lado del servidor, un secreto de cliente por un canal privado. Guarde el secreto en su servidor; nunca lo incluya en un navegador ni en una app móvil. Avísenos cuando cambie una URI de redirección. Rotamos el secreto o desactivamos la app cuando lo pida.

Lo que recibe su app

  • sub: un identificador de usuario estable y opaco. Guarde este valor, no el correo.
  • email y email_verified, que hoy siempre es false.
  • name, given_name, family_name, preferred_username, nickname.
  • Un token de actualización por 30 días con offline_access.
  • Nunca los nombres de grupos internos de ASL, ni nada que no haya pedido.

Nuestra política de privacidad cubre la cuenta; los términos y el aviso de su app cubren lo que su app haga con las afirmaciones.

Guía para desarrolladores

Integre Iniciar sesión con Auto Secure Login

Todo lo que sigue es OpenID Connect estándar. Lea los endpoints del documento de descubrimiento en lugar de copiarlos; ahí también aparecen los tipos de respuesta, los métodos PKCE y los algoritmos de firma admitidos. En las tablas, <slug> representa su ID de cliente.

Endpoints

Emisorhttps://login.autosecurelogin.com/application/o/<slug>/
Descubrimientohttps://login.autosecurelogin.com/application/o/<slug>/.well-known/openid-configuration
Autorizaciónhttps://login.autosecurelogin.com/application/o/authorize/
Tokenhttps://login.autosecurelogin.com/application/o/token/
UserInfohttps://login.autosecurelogin.com/application/o/userinfo/
Llaves (JWKS)https://login.autosecurelogin.com/application/o/<slug>/jwks/
Cierre de sesiónhttps://login.autosecurelogin.com/application/o/<slug>/end-session/

Alcances y afirmaciones

AlcanceLo que recibe
openid (obligatorio)sub, un identificador de usuario estable y opaco. Guarde este valor, no el correo.
emailemail y email_verified. Por ahora la marca siempre es false; verifique la dirección usted mismo si depende de ella.
profilename, given_name, family_name, preferred_username, nickname. Las apps externas nunca reciben los nombres de grupos de ASL.
offline_accessUn token de actualización, válido por 30 días.

Los tokens de acceso duran 10 minutos. Los tokens de identidad se firman con RS256; compruebe la firma contra el endpoint JWKS y luego iss, aud, exp y su nonce.

El flujo de inicio de sesión

  1. Envíe a la persona al endpoint de autorización con response_type=code, su client_id, redirect_uri, scope=openid email profile, un state aleatorio, un nonce aleatorio y un code_challenge PKCE con code_challenge_method=S256. PKCE es obligatorio para clientes públicos y recomendado para todos.
  2. La persona entra a ASL en inglés o en español: contraseña, llave de acceso o una cuenta vinculada de Google, Microsoft, Apple o GitHub, más su verificación en dos pasos. ASL pregunta una sola vez si permite su app; la respuesta se recuerda durante cuatro semanas.
  3. ASL regresa a su redirect_uri con code y su state. Compruebe state y luego envíe por POST el código, la misma redirect_uri, su code_verifier y sus credenciales de cliente al endpoint de token.
  4. Valide el token de identidad. Llame a UserInfo con el token de acceso si necesita las afirmaciones de nuevo.
  5. Para cerrar la sesión de la persona también en ASL, envíela al end_session_endpoint del documento de descubrimiento.

Un ejemplo completo

Suponga que ShopCo registra una app web del lado del servidor y recibe el ID de cliente asl-ext-shopco para la URI de redirección https://shop.example.com/auth/callback. Su enlace de inicio de sesión envía a la persona a https://login.autosecurelogin.com/application/o/authorize/ con estos parámetros, unidos con &:

client_idasl-ext-shopco
redirect_urihttps://shop.example.com/auth/callback, codificada como URL
response_typecode
scopeopenid email profile
stateun valor aleatorio guardado en la sesión de la persona
nonceun segundo valor aleatorio guardado en la sesión
code_challengebase64url del SHA-256 de un code_verifier aleatorio
code_challenge_methodS256

Cuando la persona permite ShopCo, ASL la regresa a https://shop.example.com/auth/callback?code=…&state=…. El servidor de ShopCo comprueba state y luego envía por POST grant_type=authorization_code, el code, la misma redirect_uri, su code_verifier y su client_id y client_secret al endpoint de token. La respuesta trae el token de identidad, un token de acceso y, con offline_access, un token de actualización. ShopCo guarda sub como clave de la cuenta y muestra el nombre de la persona.

El botón

Use este botón, o uno propio que diga Iniciar sesión con Auto Secure Login. Apúntelo a su propia ruta que inicia el flujo. Nunca enlace una página estática directamente al endpoint de autorización, porque state, nonce y el reto PKCE deben ser nuevos en cada inicio de sesión.

Una vista previa del botón (no es un enlace de inicio de sesión real):

Copie las reglas .asl-signin de asl-signin.css a su hoja de estilos, aloje una copia de asl-mark.svg y use este marcado, con href apuntando a su propia ruta:

<a class="asl-signin" href="/auth/asl/login"><img src="/asl-mark.svg" alt="" width="20" height="20"> Iniciar sesión con Auto Secure Login</a>

Agregue asl-signin--light a la lista de clases sobre un fondo claro. No dé a entender que ASL respalda su app y no altere la marca.

Reglas y límites

  • Pida solo los alcances que use. No comparta lo que recibe con terceros sin el consentimiento de la persona y bórrelo cuando ella elimine su cuenta con usted.
  • ASL puede desactivar una app en cualquier momento. Eso bloquea los nuevos inicios de sesión y revoca sus tokens.
  • El valor sub es el mismo para una persona en todas las apps externas, así que dos apps podrían cruzar a sus usuarios. Trátelo como dato personal.
  • email_verified hoy siempre es false. Una app que necesite una dirección verificada la verifica por su cuenta.
  • El registro, los cambios de URI de redirección, la rotación del secreto y la baja los hace ASL a petición; no hay una consola para desarrolladores.
  • Las páginas de inicio de sesión se ofrecen en inglés y en español. Las páginas de su app son suyas.

Los términos del servicio se aplican a la cuenta ASL misma, y la página de seguridad explica cómo reportar un problema.

Preguntas de desarrolladores

Iniciar sesión con Auto Secure Login: preguntas de desarrolladores

¿Iniciar sesión con Auto Secure Login es un inicio de sesión OpenID Connect estándar?

Sí. ASL es un proveedor OpenID Connect sobre el flujo de código de autorización de OAuth 2.0 con PKCE, así que funciona cualquier biblioteca cliente certificada de OpenID Connect. No hay un SDK que instalar.

¿Tengo que guardar contraseñas o manejar la verificación en dos pasos yo mismo?

No. ASL guarda la contraseña o la llave de acceso, ejecuta la verificación en dos pasos y muestra la pantalla de consentimiento. Su app recibe un token de identidad firmado con un identificador estable y las afirmaciones que pidió.

¿Las personas pueden usar una cuenta de Google, Microsoft, Apple o GitHub?

Sí. Una cuenta ASL puede crearse con contraseña o mediante Google, Microsoft, Apple o GitHub. En cualquier caso su app ve una sola identidad ASL y nunca habla con esos proveedores.

¿Cómo se registra una app?

Escriba a contact@autosecurelogin.com con el nombre de la app, quién la publica, cada URI de redirección exacta y si la app puede guardar un secreto. Una persona revisa el registro; no hay una consola de autoservicio.

¿Qué recibe mi app sobre la persona?

Con los alcances openid, email y profile: un identificador de usuario estable y opaco, el correo, el nombre y el nombre de usuario. ASL nunca envía sus nombres de grupos internos a apps externas, y email_verified hoy siempre es false.

¿Funciona en español?

Sí. Las pantallas de inicio de sesión, verificación en dos pasos y consentimiento se ofrecen en inglés y en español, y esta guía existe en ambos idiomas.

Ponga el botón en su app.

Envíe el nombre de la app, quién la publica y las URI de redirección, y una persona revisa el registro.

Help / Ayuda