Modular Interaction Server

Summary

The interaction server's role is to interact with the end-user.

The objective of this proposal is to un-bundle the interaction server (IS) from the Authorization Server (AS). We want to allow this for several reasons:

1. Separation of concerns: the AS manages the backend service (state management, crypto, etc.) while the IS manages the user facing components (allowing also a consistent design system and/or a platform specific UI for constrained devices). This makes it easier to adapt, scale, evolve and secure.
2. Privacy: un-bundling the interaction also enables new ways to locate where it is done; we may allow the Client to select his preferred IS, which can be operated by a different organization than the AS (possibly the Client itself may provide that facility) - cf PbD

This use case is meant to be optional, and should be implemented with minimal impact for Clients (except from optional parameters). This means the outside protocol remains the same, and whether this feature is implemented is an implementation choice.

How is that different from what currently exists?

Currently the interaction is managed within the AS. In that sense, we have a monolithic AS.
Instead, we suggest an internal protocol support that can either deploy the AS and the IS together or separately, depending on the requirements.

High-level scenario

An on-device app gets the information it needs to draw a consent UI, and continues the request without it needing to have a full view of everything back at the server.

The simplified flow would be:

1. The Client discusses with the RS to know what information is required
2. The Client makes the grant request to the AS Optionally, the Client may directly specify in the request which IS it wants to use (https://interactionserver.example.com). If this parameter is not provided, the AS will provide one (which is currently the default behavior). Also the Client details what user consent needs to be asked to the end-user. Currently this is done through the AS but one could also implement a direct communication of these parameters to the IS for privacy reasons.
3. The IS displays the consent UI
4. The AS is notified and mints the access token
5. The Client uses the access token to access protected resources at the RS

This would apply also for more advanced cases (multistep) and would be fully compatible with the core protocol (signing requests, support for OIDC, etc.).

Previous art and other references

In the context of OAuth2, ory has developed a modular approach instead of a monolithic architecture. One aspect relates to how UI components are developed in dedicated project. ORY Kratos has no user interface included. Instead, it defines HTTP flows and APIs that make it simple to write your own UI in a variety of languages and frameworks. To see an example implementation: https://github.com/ory/hydra-login-consent-node

In the context of XYZ, https://github.com/acertio/mvp_gnap_interact provides a basic implementation (not complete, but gives a concrete idea).

See also Decompose GS