Authorization

Summary

Authorization in Open Payments refers to the process by which a client obtains permission from a resource owner to access and perform operations on protected resources.

Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) as the mechanism by which the piece of software, known as a client instance (or client for short), is delegated authorization to use the Open Payments APIs to interface with supported accounts.

For ASEs

This page covers authorization from the perspective of a client developer requesting grants. If you’re implementing Open Payments at your institution, refer to Authorization server for the server-side mechanics, including how to process grant requests, manage interactive sessions, and validate access tokens.

Grants and access tokens

A grant is an authorization issued by the resource owner (RO) that allows a client to access specific resources. The grant specifies the type of actions the client is allowed to perform. Grants may require user interaction and can be contingent on the RO’s consent.

An access token is issued after a grant request is approved by the authorization server. This token serves as a credential that the client uses to authenticate itself when making requests to access protected resources. The access token contains information about the permissions granted, including the specific actions the client can perform and the resources it can access.

The authorization server is the system that issues these tokens. It is operated by the ASE and is reachable at the URL published in the authServer field of every wallet address response. For details on what the authorization server does internally, refer to Authorization server.

Grant types

This section outlines the different types of grants that clients can request within Open Payments. While the flow often begins with an incoming payment grant, there are scenarios where other grant types may be requested first.

incoming-payment

A client typically begins the Open Payments flow by requesting an incoming payment grant from the authorization server on the recipient side. However, there are instances where the client may request an outgoing payment grant first, such as in the case of Web Monetization.

The client can request a single grant to create multiple incoming payments for different Open Payments-enabled accounts as long as each account belongs to the same ASE ? Account servicing entity .

Incoming payment grants are non-interactive by default, meaning interaction by an individual (typically the client’s user) isn’t required for the authorization server to issue an access token. Clients can use directed identity for incoming payment grant requests.

quote

After the client receives an incoming payment grant and an incoming payment resource is created on the recipient’s account, the client requests a quote grant from the authorization server on the sender side. The client can request a single grant to create multiple quotes for different Open Payments-enabled accounts as long as each account belongs to the same ASE ? Account servicing entity .

Quote grants are non-interactive by default, meaning interaction by an individual (typically the client’s user) isn’t required for the authorization server to issue an access token. Clients can also use directed identity for quote grant requests.

outgoing-payment

Having progressed through the incoming payment and quote portions of the Open Payments flow, the client is ready to request an outgoing payment grant from the authorization server on the sender side.

Open Payments requires outgoing payment grant requests to be interactive. When a grant request is interactive, it means explicit interaction by an individual (typically the client’s user) is a required step in the delegation process. Your client must redirect the user to the interaction URI returned by the authorization server, then handle the redirect back to your app after consent is collected.

After a successful interaction, the client must issue a Grant Continuation request so the authorization server knows to issue an access token.

More about authorization

For a deeper dive into authorization topics including GNAP and requesting grants, refer to Grant negotiation and authorization and the other pages under Identity and access management.