MX-Hosted Implementations
In general, Data Access is hosted by MX using the Google Cloud Platform.
Settings and configurations specific to your needs can be made from within the Data Access administrator dashboard once MX has set up your environment. The sections that follow explain all the settings and configurations available to you, setup, and testing. We also cover how to embed the customer consent-management dashboard in your existing user interfaces.
Requirements
There are several requirements for an MX-hosted implementation of Data Access.
- You must have an OIDC provider (such as Okta) for both customer authentication and administrator authentication. You can use the same or separate providers for customers and administrators.
- Your existing backend API must be accessible from the outside. This is necessary for Data Access to get data from your systems.
Setup and Testing
MX will set up a generic development/testing environment for you using a temporary OIDC provider. This enables your admins and developers to log in and make changes to all settings (like host, branding, OIDC, etc) from within the administrator dashboard.
MX also provides a dummy data recipient called Centz for testing purposes. This will allow you to test workflows, sending and receiving data, etc.
Settings and Configuration
You can access these settings from within the Data Access data-provider administration widget, for example, at https://access.your-domain.com/admin/settings.
| Setting | Description | Required? |
|---|---|---|
| Client auth method | Only basic authorization is supported. This must be configured separately for both admin and customer. | Yes |
| Client ID | The client ID issued by the authorization server. This must be configured separately for both admin and customer. | Yes |
| Client secret | The client secret issued by the authorization server. This must be configured separately for both admin and customer. | Yes |
| Colors | Your financial institution’s brand colors. These are used for link and button colors throughout Data Access UIs. | Yes |
| Disable OAuth PKCE code challenge | This may be useful for debugging. Defaults to false. | No |
| Discovery URI | OIDC configuration metadata endpoint. This must be configured separately for both admin and customer. | No |
| Honeybadger API key | The API key provided by Honeybadger. Used to monitor system errors produced by the application. | No |
| Institution name | The human-readable name of your financial institution. | Yes |
| Logo | Your financial institution's logo image. This image is shown in the end-user consent flow and the data recipient portal. | Yes |
| OIDC debug | This enables extra logging for debugging. Defaults to false. | No |
| Provider authorize URI | OAuth 2 authorization endpoint. This must be configured separately for both admin and customer. | Required when no discovery URI is set. |
| Provider token URI | OAuth 2 token endpoint. This must be configured separately for both admin and customer. | Required when no discovery URI is set. |
| Provider user info URI | OIDC user information endpoint. This must be configured separately for both admin and customer. | Required when no discovery URI is set. |
| Public URL | The public-facing URL of your Data Access instance without a trailing slash. This setting is used in the redirect URIs that must be registered for both admin and customer authorization services. Example: https://access.your-domain.comAdmin authorization redirect URI: https://access.your-domain.com/admins/oidc_callbackCustomer authorization redirect URI: https://access.your-domain.com/customers/oidc_callback | Yes |
| Scope | Space-separated list of scope(s) needed for admin token generation. This must be configured separately for both admin and customer. | Yes |
| Shared secret | This is a symmetric key used in AES256 encryption for the customer consent-management flow. It must be a random 32 bytes represented as a Base64 string. For example, Jx2qSDdJy6BJfkjH7PPZ6OPnjbjd/qNI2vgbCRT30Qw=. The example given here is valid and can be used in development and testing environments, but can't be used in production. Production shared secrets can either be provided securely by MX or generated on your end. | Yes |