# Activar la creación/inicio de sesión en un servicio externo cuando un usuario inicia sesión en discourse

**URL:** <https://meta.discourse.org/t/triggering-account-creation-login-on-external-service-when-a-user-logs-in-on-discourse/340359>\
**Category:** Development\
**Created:** [4 Diciembre, 2024 13:18 UTC](https://meta.discourse.org/t/triggering-account-creation-login-on-external-service-when-a-user-logs-in-on-discourse/340359 "2024-12-04T13:18:09Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![renato](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/renato/32/383632_2.png) [@renato](https://meta.discourse.org/u/renato)\
**Post date:** [4 Diciembre, 2024 15:36 UTC](https://meta.discourse.org/t/triggering-account-creation-login-on-external-service-when-a-user-logs-in-on-discourse/340359/2 "2024-12-04T15:36:45Z")

</div>

No conozco lo suficiente de tu stack o caso de uso, pero creo que he resuelto un problema similar antes y algunas ideas pueden serte útiles.

Tengo una aplicación Next.js donde necesito que el lado del cliente tenga un JWT válido para hacer llamadas a mi API de backend si hay una sesión de Discourse.

Para esto, utilizo [Discourse como mi proveedor de identidad a través de DiscourseConnect](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974).

En mi caso, lo hago con una única llamada `fetch` del lado del cliente con `{ credentials: "include" }`, lo que solo funciona porque tengo todo configurado con un solo dominio y la llamada `fetch` sigue las redirecciones de forma transparente.

Mi cliente llama a un `/auth/token` personalizado, que verifica la existencia de `_t` (solo para evitar una redirección inútil en caso contrario) y devuelve una redirección a una URL segura `/session/sso_provider` construida siguiendo la documentación del tema enlazado, con `nonce`/`sso`/`sig`, y un `return_sso_url` que apunta a un `/auth/callback` personalizado, que extraerá los datos enviados por Discourse, construirá y devolverá un token JWT que mi cliente podrá usar a partir de ese momento.

> [@Chris\_Dawson](#):
>
> ¿Hay una forma más inteligente de acceder de forma segura a la dirección de correo electrónico de un usuario conectado? No creo que esto deba ocurrir en el lado del cliente, y preferiría hacerlo en el lado del servidor por obvias razones de seguridad.

Creo que tu caso de uso puede resolverse de manera similar.

> [@Use Discourse as an identity provider (SSO, DiscourseConnect)](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974):
>
> So you want to use Discourse as an identity provider for your own web app? Great! Let’s get started. Enable [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) provider setting Under Discourse admin site settings (/admin/site\_settings) enable setting enable discourse connect provider and add a secret string to discourse connect provider secrets (used to hash SSO payloads). Implement [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true) in your web app: Generate a random [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). Let’s call this value NONCE. Save it temporarily so that you can verify it with the …

---

_[View the full topic](https://meta.discourse.org/t/triggering-account-creation-login-on-external-service-when-a-user-logs-in-on-discourse/340359)._
