El flujo completo

Catálogo de Produtos / El flujo completo
Cómo funciona, de punta a punta

El flujo completo de una autorización

Desde que el PSBI pide acceso hasta que consume los datos del Usuario Final. Es el camino sin desvíos: todo lo que puede salir mal está fuera de esta página, a propósito.

JornadaCompartición de datos
PerfilFAPI 2.0
ConsentimientoRAR + Grant Management

01 Quién participa

ActorPapel en el flujo
Usuario FinalEl titular de los datos. Autentica y consiente.
Aplicación del PSBIQuien pide el acceso y después consume los datos.
Jornada PSBILa fachada de la plataforma. Habla el protocolo del SFA en nombre del PSBI.
Authorization ServerAutoriza, registra el consentimiento y emite los tokens.
Institución (IPI)Autentica al titular, muestra la pantalla de consentimiento y sirve los datos.
DirectorioEl ancla de confianza: quién está habilitado y con qué claves.

02 La secuencia

Cuatro tramos: preparar la solicitud, autorizar, obtener el token, consumir.

sequenceDiagram
    autonumber
    actor U as Usuario Final
    participant P as Aplicación del PSBI
    participant J as Jornada PSBI
    participant AS as Authorization Server
    participant I as Institución (IPI)
    participant D as Directorio

    P->>J: Iniciar jornada (datos solicitados, vigencia)
    Note over J: Arma la solicitud firmada del SFA
    J->>AS: PAR - solicitud firmada (mTLS)
    AS-->>J: request_uri
    J-->>P: URL de autorización

    P-->>U: Redirige a la autorización
    U->>AS: Abre la autorización
    AS->>D: Verifica estado y claves del participante
    D-->>AS: Participante activo
    AS-->>U: Redirige a la institucion

    U->>I: Se autentica con MFA / SCA
    I-->>U: Pantalla de consentimiento de la institucion
    U->>I: Aprueba
    I->>AS: Decisión del titular
    Note over AS: Registra el consentimiento como Authorised
    AS-->>U: Redirige de vuelta al PSBI

    U->>P: Retorno de la jornada
    P->>J: Concluir jornada
    J->>AS: Canje por el token (mTLS)
    AS-->>J: access_token + grant_id
    J-->>P: Credenciales listas

    Note over AS,I: Asíncrono
    AS-)I: Evento de consentimiento (webhook)

    P->>I: Consume las APIs reguladas con el token
    I-->>P: Datos del Usuario Final

03 Qué hace cada tramo

  1. Preparar la solicitud — pasos 1 a 5
    La aplicación dice qué datos quiere y por cuánto tiempo. La plataforma arma la solicitud firmada y la envía al Authorization Server antes de que el navegador vea nada: los parámetros nunca viajan en la URL.
  2. Autorizar — pasos 6 a 14
    El Authorization Server comprueba contra el Directorio que el participante esté habilitado, y lleva al titular a la institución. Ahí el titular se autentica con MFA/SCA y aprueba en la pantalla de su propio banco. El consentimiento queda registrado como Authorised.
  3. Obtener el token — pasos 15 a 18
    La plataforma canjea el retorno por un access token ligado al certificado de quien lo pidió, y por el grant_id que identifica ese consentimiento.
  4. Consumir — pasos 19 y 20
    Con el token, la aplicación llama a las APIs reguladas. Del otro lado, los interceptors comprueban en el borde que el consentimiento cubra la operación.
El evento no está en el camino crítico

El webhook hacia la institución sale en paralelo, no bloquea la jornada. Es así como la institución se entera de los cambios de estado posteriores — revocación, expiración, cambio de alcance.

04 Lo que este diagrama no muestra

Es el camino feliz. Quedan fuera, y cada uno tiene su propio tratamiento:

  • El titular rechaza el consentimiento, o abandona la jornada.
  • El participante está Inactivo o Suspendido en el Directorio.
  • El consentimiento se revoca o expira después de otorgado.
  • El alcance cambia — replace o merge — lo que exige una nueva aprobación del titular.
  • Iniciación de pagos, que agrega pasos entre la autorización y el consumo.

← Volver a Open Finance Chile · Ver los contratos · Ver los interceptors