Saltar al contenido principal

Inicio de sesión OAuth con DingTalk, WeCom, Lark, Infoflow y WeChat usando Casdoor

· 12 min de lectura
Yang Luo
Yang Luo
Casdoor Maintainer

Casdoor tiene proveedores OAuth integrados para DingTalk, WeCom (WeChat Work), Lark (Feishu), Baidu Infoflow y WeChat. Creas una aplicación en la consola de desarrolladores de cada proveedor, pegas sus credenciales en un proveedor de Casdoor y agregas el proveedor a tu aplicación. Casdoor ejecuta el flujo del proveedor (escaneo de QR en escritorio o inicio de sesión dentro del propio cliente del proveedor), obtiene el token de acceso corporativo donde el proveedor lo requiere, y mapea el ID de usuario del proveedor a un usuario de Casdoor. Tu aplicación solo se comunica con Casdoor mediante OIDC y nunca ve una cabecera de DingTalk, un user_ticket de WeCom ni un unionid de WeChat. Para DingTalk, WeCom y Lark, un sincronizador también puede importar todo el directorio organizacional antes del primer inicio de sesión.

De un vistazo​

ProveedorAplicación que creasDónde inician sesión los usuariosID que vincula al usuario de CasdoorCorreo electrónico y teléfonoSincronizador de directorio
DingTalkAplicación interna (AppKey, AppSecret)Página de inicio de sesión de DingTalk, login.dingtalk.comopenId; unionid se convierte en el nombre de usuarioDel perfil, reemplazado por el directorio corporativo; tratado como verificadoSí
WeComAplicación autoconstruida (CorpID, Secret, AgentId), o de tercerosInicio de sesión web (QR, o inicio de sesión rápido desde el escritorio de WeCom) o inicio de sesión silencioso dentro de WeComuserid (interno), open_userid (de terceros)Solo correo electrónico con snsapi_privateinfo; no se lee el teléfonoSí
Lark / FeishuAplicación personalizada (App ID, App Secret)Página de inicio de sesión de Lark, Feishu o Lark globalopen_id; el nombre de usuario es user_id, si no union_id, si no open_idSí, si la aplicación tiene permisos de contactoSí
Baidu InfoflowAplicación interna (CorpID, Secret, AgentID)Página de autorización de Infoflowuserid, también el nombre de usuarioCorreo electrónicoNo
WeChatAplicación de sitio web en la Plataforma Abierta, más una Cuenta OficialEscaneo de QR en PC; dentro del navegador de WeChat a través de la Cuenta Oficialunionid, si no openidNingunoNo

Los pasos de configuración para cada uno están en la documentación: DingTalk, WeCom, Lark, Infoflow y WeChat. Esta publicación explica qué sucede detrás de cada uno.

Qué ve tu aplicación​

Todos los proveedores de la tabla terminan igual. Casdoor intercambia el código del proveedor, encuentra o crea al usuario en la organización y luego emite su propio código de autorización para tu aplicación. Tu aplicación lo canjea en el endpoint de token de Casdoor y obtiene un token de identificación y un token de acceso de Casdoor, firmados con el certificado de la aplicación. Las reclamaciones provienen del registro de usuario de Casdoor: nombre, nombre para mostrar, correo electrónico, teléfono, avatar, grupos.

El código de tu backend es el mismo para los cinco. Cualquier biblioteca OIDC funciona; consulta la referencia de OAuth 2.0 y OIDC y, para una guía completa, SSO con Spring Boot y OIDC. Si necesitas la API propia del proveedor más adelante, Casdoor almacena el token de acceso del proveedor en el usuario, como se describe en Proveedores OAuth.

DingTalk​

Crea una aplicación interna en la Plataforma Abierta de DingTalk y copia su AppKey y AppSecret en el Client ID y el Client secret del proveedor. La página de inicio de sesión envía al usuario a https://login.dingtalk.com/oauth2/auth con scope=openid y prompt=login consent. Después de que el usuario confirma, Casdoor realiza cuatro llamadas:

  1. POST https://api.dingtalk.com/v1.0/oauth2/userAccessToken convierte el código en un token de acceso de usuario.
  2. GET https://api.dingtalk.com/v1.0/contact/users/me devuelve el openId, unionId, apodo, avatar, correo electrónico y móvil del usuario. Esto necesita el permiso Contact.User.Read en la aplicación.
  3. POST https://api.dingtalk.com/v1.0/oauth2/accessToken con appKey y appSecret devuelve el token de acceso corporativo (de la aplicación).
  4. Con ese token, topapi/user/getbyunionid mapea el unionid al userid corporativo, y topapi/v2/user/get lee el registro del directorio.

Si el usuario no es miembro de la organización que posee la aplicación, el paso 4 falla con el error 60121 de DingTalk y el inicio de sesión se detiene. Si la búsqueda en el directorio tiene éxito, el correo electrónico y el móvil del directorio reemplazan a los personales, unionid se convierte en el nombre de usuario, y el puesto de trabajo se conserva como una reclamación adicional.

El token de acceso corporativo y su cabecera​

DingTalk tiene dos generaciones de API que aceptan el mismo token en lugares diferentes:

GET https://api.dingtalk.com/v1.0/contact/users/me
x-acs-dingtalk-access-token: <token>
POST https://oapi.dingtalk.com/topapi/v2/user/get?access_token=<token>
Content-Type: application/json

{"userid": "<userid>"}

La nueva API en api.dingtalk.com lee el token solo de la cabecera x-acs-dingtalk-access-token. Llámala sin esa cabecera (o con Authorization: Bearer) y responderá AuthenticationFailed.MissingParameter, nombrando la cabecera. Los endpoints antiguos de oapi.dingtalk.com aún aceptan un parámetro de consulta access_token. Casdoor usa ambos: la cabecera para users/me, el parámetro de consulta para las dos llamadas topapi, con el token corporativo de v1.0/oauth2/accessToken en ambos lugares. DingTalk documenta que este token es válido durante 7,200 segundos y pide a los llamantes que lo almacenen en caché por aplicación. DingTalk también marca el endpoint antiguo gettoken como legado para nuevas aplicaciones.

Casdoor cuenta el correo electrónico y el teléfono que devuelve DingTalk como verificados, por lo que la regla de vinculación predeterminada (correo electrónico, luego teléfono) puede adjuntar un inicio de sesión de DingTalk a un usuario existente. Consulta cómo Casdoor vincula cuentas.

WeCom (WeChat Work)​

Un proveedor de WeCom tiene un Sub type y un Method:

  • Internal con Normal envía al usuario al inicio de sesión web de WeCom, login.work.weixin.qq.com/wwlogin/sso/login con login_type=CorpApp. WeCom muestra un código QR, o un inicio de sesión rápido con un clic cuando la versión de escritorio de WeCom está en ejecución y ha iniciado sesión.
  • Internal con Silent utiliza open.weixin.qq.com/connect/oauth2/authorize con el agentid de la aplicación. Esta es la opción a utilizar para páginas abiertas dentro del cliente de WeCom.
  • Third-party utiliza login_type=ServiceApp y el secreto del proveedor de servicios (get_provider_token), luego get_login_info, y vincula al usuario mediante open_userid.

Para aplicaciones internas, Casdoor obtiene el token corporativo desde cgi-bin/gettoken con el CorpID y el Secret de la aplicación, luego intercambia el código por el userid del miembro. Un visitante que no es miembro regresa con un openid en su lugar, y Casdoor rechaza el inicio de sesión. El token es un parámetro de consulta en cada llamada a WeCom; WeCom indica que normalmente dura 7,200 segundos y que gettoken tiene una limitación de tasa.

La dirección de correo electrónico es el aspecto a tener en cuenta. WeCom dejó de devolver avatar, género, móvil y correo electrónico desde la API de lectura de miembros (user/get) para las aplicaciones autogestionadas creadas después de las 20:00 del 20-06-2022. Para obtener el correo electrónico, configure el ámbito del proveedor como snsapi_privateinfo. WeCom devuelve entonces un user_ticket, que Casdoor canjea en getuserdetail. WeCom requiere que el administrador seleccione los campos sensibles en la configuración de la aplicación y que el miembro dé su consentimiento, y nunca proporciona estos campos a las aplicaciones de terceros. Casdoor no lee el número de teléfono desde WeCom.

Lark y Feishu​

Cree una aplicación personalizada en la Feishu Open Platform o en la plataforma global de Lark y copie el App ID y el App Secret. Active Use global endpoint en el proveedor para Lark (open.larksuite.com); déjelo desactivado para Feishu (open.feishu.cn).

Casdoor primero obtiene un tenant_access_token desde auth/v3/tenant_access_token/internal, luego publica el código en authen/v1/access_token con ese token en una cabecera Authorization: Bearer. La respuesta incluye open_id, union_id, user_id, email, email empresarial y móvil. Feishu devuelve los sensibles solo cuando la aplicación tiene el permiso correspondiente:

CampoPermiso de Feishu
user_idcontact:user.employee_id:readonly
emailcontact:user.email:readonly
enterprise_emailcontact:user.employee:readonly
mobilecontact:user.phone:readonly

Sin ellos, el inicio de sesión sigue funcionando: el nombre de usuario recurre de user_id a union_id y luego a open_id. Casdoor utiliza enterprise_email cuando email está vacío y trata tanto el email como el teléfono como verificados. Feishu ahora enumera el endpoint v1 access_token como una versión histórica, pero todavía se sirve.

Baidu Infoflow​

Infoflow (如流) es la aplicación de trabajo de Baidu. Registre una aplicación en el administrador de Infoflow, otórguele permisos de libreta de direcciones y copie el CorpID, Secret y AgentID en el proveedor con el subtipo Internal. La página de inicio de sesión va a https://xpc.im.baidu.com/oauth2/authorize. Casdoor luego llama a qy.im.baidu.com/api/gettoken con el CorpID y Secret, intercambia el código y el AgentID por el userid del miembro en api/user/getuserinfo, y lee el nombre, avatar y email desde api/user/get. El userid se convierte tanto en el ID vinculado como en el nombre de usuario, y el email cuenta como verificado. No hay sincronizador de Infoflow, por lo que los usuarios se crean en el primer inicio de sesión.

WeChat​

El inicio de sesión de WeChat tiene dos partes, y generalmente necesita ambas:

  • Subtipo Web: una aplicación de sitio web en la Plataforma Abierta de WeChat. La página de inicio de sesión en PC muestra un código QR desde open.weixin.qq.com/connect/qrconnect con scope=snsapi_login; el usuario lo escanea con la aplicación de WeChat.
  • Subtipo Mobile, o el segundo par de credenciales del mismo proveedor: una Cuenta Oficial. Dentro del navegador de WeChat, un código QR es inútil, por lo que Casdoor cambia a connect/oauth2/authorize con snsapi_userinfo y el AppID de la Cuenta Oficial. Si no se configura ninguna Cuenta Oficial, Casdoor le dice al usuario que abra la página en un navegador externo.

WeChat no devuelve email ni teléfono, solo openid, unionid, apodo y avatar. Casdoor vincula al usuario por unionid cuando WeChat envía uno, recurriendo a openid, y también almacena el openid específico de la aplicación. WeChat da a un usuario el mismo unionid en todas las aplicaciones y Cuentas Oficiales bajo una sola cuenta de la Plataforma Abierta, así que vincule su aplicación de sitio web y su Cuenta Oficial a la misma cuenta de la Plataforma Abierta. De lo contrario, un usuario que escanea en un PC y luego inicia sesión en un teléfono se convierte en dos usuarios de Casdoor.

Importar el directorio primero​

Para DingTalk, WeCom y Lark, un synchronizer puede extraer usuarios y departamentos según un calendario programado, por lo que las cuentas existen antes de que alguien inicie sesión y los departamentos se convierten en grupos de Casdoor. Cada uno usa un token corporativo de la API de directorio del proveedor: el synchronizer de DingTalk recorre los departamentos recursivamente, el synchronizer de WeCom recurre a user/list_id y user/get para las aplicaciones creadas después del 15-08-2022, y el synchronizer de Lark tiene una configuración Lark platform para elegir entre Feishu o Lark global.

El synchronizer de WeCom escribe el userid por el que el proveedor de WeCom vincula, por lo que los usuarios sincronizados inician sesión directamente. Los synchronizers de DingTalk y Lark almacenan el userid / user_id del directorio, mientras que el inicio de sesión vincula por openId / open_id. Su primer inicio de sesión coincide a través de la regla de vinculación sobre email o teléfono en su lugar, lo cual funciona porque ambos proveedores informan esos datos como verificados.

Inicio de sesión por QR y recuperación de cuenta​

El inicio de sesión con QR traslada el problema de la contraseña al teléfono: si un usuario pierde su cuenta de WeChat o DingTalk, no podrá escanear. Dado que cada una de estas identidades está vinculada a un usuario de Casdoor en lugar de ser el usuario mismo, este aún puede iniciar sesión con un código de verificación o restablecer la contraseña mediante el flujo de recuperación de contraseña, siempre que la aplicación tenga un proveedor de correo electrónico o SMS y el usuario tenga una dirección registrada. DingTalk y Lark completan esta información desde el directorio; para WeChat, solicite un número de teléfono durante el registro. Para mostrar más de una de estas opciones en la página, consulte los métodos de inicio de sesión.

Referencias​