Autenticación y varios usuarios

Una aplicación, varias personas

La aplicación externa identifica al software que se conecta. Una aplicación compartida puede atender a muchos usuarios. Cada persona se autentica en Mopdow, autoriza los scopes y recibe su propio token; conserva sus permisos, sharing y restricciones. Creá aplicaciones separadas cuando cambien el software, los callbacks, las políticas o el ambiente, no por cada persona.

El administrador puede restringir usuarios y perfiles permitidos. El permiso api.enabled, el scope solicitado y los permisos de negocio deben cumplirse a la vez. Un scope no otorga por sí solo acceso a un registro.

Antes de conectar, asigná a cada usuario un perfil o conjunto de permisos con API habilitada (api.enabled). El nombre del conjunto es libre; no requiere un nombre especial. La pantalla de consentimiento comprueba ese acceso y muestra la cuenta y el ambiente. El servidor vuelve a verificar usuario, aplicación, scopes y permisos al emitir o renovar un token: una autorización antigua no conserva permisos revocados.

Personas: Authorization Code con PKCE

Usá PKCE S256, un state aleatorio validado al volver, y una redirect URI registrada exactamente. No pongas un client secret en una aplicación pública, navegador o configuración compartida de IA.

1. Descubrí el authorization server en /.well-known/oauth-authorization-server/api/auth.
2. Redirigí al endpoint authorization_endpoint con response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256 y resource.
3. Intercambiá el código en token_endpoint enviando grant_type=authorization_code, code, client_id, redirect_uri, code_verifier y el mismo resource.
4. Enviá Authorization: Bearer ACCESS_TOKEN en cada llamada. No uses el ID token como access token.
5. Solicitá offline_access solamente si necesitás renovación. Guardá los tokens en un almacén protegido y respetá la rotación del refresh token.

Los access tokens de personas duran 15 minutos. Sin offline_access y el grant refresh_token aprobado, al vencer necesitás iniciar el flujo OAuth nuevamente. No amplíes scopes automáticamente para resolver un error de permisos.

Canal	Valor de resource
REST y CLI	urn:mgweb:erp-api
MCP	https://TU_AMBIENTE/api/v1/mcp (URL canónica completa)

Las audiencias son distintas. Un token REST no se acepta en MCP ni viceversa. No combines ambos recursos en un token. La sesión de la interfaz tampoco reemplaza el bearer token.

Servicios: Client Credentials

Este flujo requiere una aplicación confidencial asociada a un usuario técnico de tipo INTEGRATION o BOT. No permite impersonar a una persona. Para REST:

$form = @{
  grant_type = 'client_credentials'
  client_id = $env:ERP_CLIENT_ID
  client_secret = $env:ERP_CLIENT_SECRET
  scope = 'data:read'
  resource = 'urn:mgweb:erp-api'
}
$token = Invoke-RestMethod "$env:ERP_SERVER_URL/api/auth/oauth2/token" -Method Post -ContentType 'application/x-www-form-urlencoded' -Body $form
# Usar $token.access_token en memoria. No imprimir ni guardar esta respuesta en logs.

No solicites openid, profile, email u offline_access con Client Credentials. Un principal BOT además necesita una corrida y las cabeceras del gobierno de agentes.

Revocación y separación de ambientes

Creá y autorizá la aplicación en cada ambiente requerido. El servidor verifica issuer, audience, tenant firmado, cliente activo, usuario activo, scopes actuales, permisos e IPs permitidas en cada solicitud. Rotar o revocar una aplicación no requiere repartir credenciales personales nuevas entre todos sus usuarios.

El alta dinámica pública de clientes OAuth está deshabilitada. Para conectar un cliente MCP debe admitir una aplicación previamente registrada; no todos los clientes externos ofrecen el mismo flujo.