redirect_uri que vas a usar esté entre sus
direcciones de retorno. Lee Crea una app.
Los datos del servidor de autorización
Si tu librería de OAuth descubre el servidor sola, dale el issuer
https://api.craqui.com y el tipo de metadata
de OAuth 2.0 (oauth-authorization-server), no el de OpenID Connect: Craqui no emite id_token.
1. Prepara el pedido en tu servidor
Cuando el propietario toca «Conectar con Craqui» en tu web, tu servidor genera tres valores nuevos para ese intento y los guarda en la sesión de esa persona (del lado del servidor, nunca en una cookie legible ni en ellocalStorage):
code_verifier: un valor aleatorio de 43 a 128 caracteres (A-Z,a-z,0-9,-,.,_,~).code_challenge: el SHA-256 delcode_verifier, en base64url y sin=.state: un valor aleatorio que ata la respuesta a esta sesión. Craqui no lo exige, pero sin él tu web queda expuesta a que alguien le haga conectar a tu usuario el negocio de otra persona (CSRF). Mándalo siempre.
openssl, para probar desde la terminal:
2. Manda al propietario a la pantalla de conexión
Redirige el navegador ahttps://www.craqui.com/oauth/authorize con estos parámetros:
scope solo puede nombrar permisos que tu app declaró al registrarse. Uno que no declaró, o uno que ninguna app
puede tener, vuelve a tu web con error=invalid_scope. Lee Permisos.
3. El propietario conecta
En la pantalla de Craqui, el propietario:- Inicia sesión, si no la tenía.
- Ve el nombre de tu app, el dominio de tu sitio y, si la aprobamos, la marca Verificada por Craqui.
- Elige el negocio. Solo aparecen los negocios donde es propietario; si tiene uno solo, ya viene elegido.
- Revisa los permisos y puede quitar cualquiera, menos el de los datos básicos del negocio.
- Toca Conectar o Cancelar.
client_id desconocido, una redirect_uri que no está
registrada, sin PKCE), Craqui no vuelve a tu web: le muestra al propietario que la conexión no está bien
configurada. Una dirección que no se pudo verificar no recibe nada.
4. Recibe la respuesta en tu dirección de retorno
Si el propietario conectó tu app, Craqui redirige a turedirect_uri con:
statees exactamente el que guardaste en la sesión de esa persona. Después, bórralo: sirve una vez.isses exactamentehttps://api.craqui.com. Si tu app se conecta a más de un servidor de autorización, así sabes que el código es de Craqui (RFC 9207).
state e iss:
Estos errores vuelven a tu web solo si quien conecta puede conectar tu app. Con una app en desarrollo, alguien
que no es propietario del negocio que la registró no vuelve a tu web: la pantalla le dice que no puede conectarla.
5. Cambia el código por tokens
El código vence a los 120 segundos y sirve una sola vez. Desde tu servidor:- La app se autentica con su identificador y su secreto en
Authorization: Basic(-uencurl), o conclient_idyclient_secreten el cuerpo. Uno de los dos, nunca los dos. - El cuerpo va como
application/x-www-form-urlencoded. redirect_uries la misma del paso 2, letra por letra.
business_ides el negocio que eligió el propietario. Guarda los tokens bajo ese id: es como sabes, sin otra llamada, a qué negocio pertenece cada par.scopeson los permisos que de verdad tiene la conexión. Pueden ser menos de los que pediste: el propietario pudo quitar alguno, y un negocio no da permisos que no aplican a él. Lee Permisos.- Guarda el refresh token cifrado, en tu base de datos. El access token vence en una hora; lo que haces después está en Tokens.
code_verifier, la redirect_uri, el código ya se usó o venció, o es de otra app), la
respuesta es 400 con error: "invalid_grant", sin decir cuál de los chequeos falló. Un code_verifier que no
tiene el formato de PKCE (43 a 128 caracteres de A-Z, a-z, 0-9, -, ., _, ~) responde antes,
con invalid_request. Si el mismo código se
presenta dos veces, Craqui además desconecta la conexión que salió de ese código: alguien más pudo haberlo
visto.
Si el negocio ya estaba conectado
Si un propietario vuelve a conectar tu app a un negocio donde ya estaba conectada, la conexión nueva reemplaza a la anterior: los tokens viejos de ese negocio dejan de funcionar y valen los que acabas de recibir, con los permisos que eligió ahora. Reemplaza lo que tenías guardado para esebusiness_id.
6. Llama a la API
El access token va en el headerAuthorization, igual que una clave:
vertical dice el tipo de negocio que conectó el propietario: léelo para saber qué rutas puede usar tu
app en ese negocio.
Desde acá, todo lo de la API vale igual: las mismas rutas, la paginación, la
idempotencia, las versiones y los errores. El token solo ve el negocio
de la conexión: ningún parámetro del pedido lo cambia. Y va solo en el header: un token en la URL o en un
cuerpo de formulario se rechaza con invalid_request.
La versión de la API de una app queda fijada al crearla, como la de una clave; el header Craqui-Version la
cambia en un pedido.
El mismo flujo en TypeScript
Conoauth4webapi (npm install oauth4webapi@3), en tu servidor. La
librería genera el PKCE y el state, y comprueba state e iss en la respuesta. session es la sesión de
servidor de quien está conectando, y saveConnection, tu propio guardado:
Este código corre en tu servidor. El secreto, el
code_verifier y los tokens nunca pasan por el navegador:
lo único que ve el navegador es la URL de la pantalla de conexión y el regreso a tu web con el código.
