Saltearse al contenido
GitHub

Autorización

Open Payments aprovecha el Protocolo de negociación y autorización de concesiones (GNAP) como el mecanismo mediante el cual se delega en el software, conocido como instancia de cliente (o cliente para abreviar), la autorización para usar las API de Open Payments para interactuar con las cuentas compatibles.

El servidor de autorización otorga permiso para que un cliente acceda a las API de pagos abiertos y los recursos de pagos entrantes incoming-payment , cotización quote y pagos salientes outgoing-payment. Lo hace mediante la emisión de tokens de acceso, que representan un conjunto de derechos de acceso y/o atributos otorgados al cliente. Con los tokens de acceso apropiados, el cliente puede realizar operaciones permitidas, como crear pagos entrantes y salientes, en nombre del propietario del recurso (RO).

Relación entre las subvenciones y los tokens de acceso

Sección titulada «Relación entre las subvenciones y los tokens de acceso»

A subvención es una autorización emitida por el RO que permite a un cliente acceder a recursos específicos. La subvención especifica el tipo de acciones que el cliente puede realizar. Las subvenciones pueden requerir la interacción del usuario y pueden depender del consentimiento de la RO. El servidor de autorización valida la subvención cada vez que el cliente usa su token de acceso.

Un token de acceso access token se emite después de que el servidor de autorización aprueba una solicitud de subvención. Este token sirve como una credencial que el cliente utiliza para autenticarse al hacer solicitudes para acceder a los recursos protegidos. El token de acceso contiene información sobre los permisos otorgados, incluidas las acciones específicas que el cliente puede realizar y los recursos a los que puede acceder.

Esta sección describe los diferentes tipos de subvenciones que los clientes pueden solicitar dentro de los pagos abiertos. Si bien el flujo a menudo comienza con una subvención de pago entrante, hay escenarios en los que primero se pueden solicitar otros tipos de subvenciones.

Un cliente generalmente comienza el flujo de pagos abiertos solicitando una subvención de pago entrante del servidor de autorización en el lado que recibe recipient side. Sin embargo, hay casos en los que el cliente puede solicitar una subvención de pago saliente primero, como en el caso de la Monetización Web.

El Cliente puede solicitar una sola subvención para crear múltiples pagos entrantes para diferentes cuentas de pagos abiertos siempre que cada cuenta pertenezca a la misma ASE Account servicing entity .

Después de que el cliente recibe una subvención de pago entrante y se crea un recurso de pago entrante en la cuenta del destinatario, el cliente solicita una subvención de cotización del servidor de autorización en el lado del servidor sender side. El cliente puede solicitar una sola subvención para crear múltiples cotizaciones para diferentes cuentas de pagos abiertos siempre que cada cuenta pertenezca a la misma ASE Account servicing entity .

Las subvenciones de cotización no son interactivas de forma predeterminada, lo que significa que no es necesaria la interacción de un individuo (generalmente el usuario del cliente) para que el servidor de autorización emita un token de acceso.

Habiendo progresado a través del pago entrante y las porciones de cotización del flujo de pagos abiertos, el cliente está listo para solicitar una subvención de pago saliente del servidor de autorización en el lado del servidor, sender side.

Los pagos abiertos requieren que las solicitudes de subvenciones de pago salientes sean interactivas. Cuando una solicitud de subvención es interactiva, significa la interacción explícita por parte de un individuo (generalmente el usuario del cliente) es un paso requerido en el proceso de delegación.

Después de una interacción exitosa, el cliente debe emitir una solicitud de continuación de subvención para que el servidor de autorización sepa emitir un token de acceso.