Identity providers
Open Payments requires any authorization server that issues interactive grants to integrate with an IdP.
An interactive grant is a grant that requires explicit user interaction/consent from the resource owner before an access token can be issued. In Open Payments, an interactive grant must be issued before an outgoing payment resource can be created.
After the interactive grant request begins and the authorization server sets the session, the server provides the client with the IdP URI in which to redirect the user.
The following diagram illustrates the flow of an interactive grant.
sequenceDiagram autonumber
Client->>Authorization server (AS): POST grant request (with interact object)
Authorization server (AS)-->>Client: 200 OK, returns interact redirect URI and continue URI
Client->>Authorization server (AS): Navigates to interact redirect URI
Authorization server (AS)->>Authorization server (AS): Starts interaction and sets session
Authorization server (AS)-->>Client: 302 temporary redirect to identity provider
URI with grant info in query string
Client->>Identity provider (IdP): Redirects to identity provider
Identity provider (IdP)->>Identity provider (IdP): Resource owner (e.g. client user)
accepts interaction
Identity provider (IdP)->>Authorization server (AS): Sends interaction choice
Authorization server (AS)-->>Identity provider (IdP): 202 choice accepted
Identity provider (IdP)->>Authorization server (AS): Requests to finish interaction
Authorization server (AS)->>Authorization server (AS): Ends session
Authorization server (AS)-->>Identity provider (IdP): 302 temporary redirect to finish URI
(defined in initial grant request)
secured with unique hash and
interact_ref in query string
Identity provider (IdP)->>Client: Follows redirect
Client->>Client: Verifies hash
Client->>Authorization server (AS): POST grant continuation request with
interact_ref in body to continue URI
Authorization server (AS)-->>Client: 200 OK, returns grant access token