Deployment and Operations

Cloudentity Platform Expected Headers

When your requests are forwarded to the Cloudentity platform, all HTTP request headers must be correct for the firewall to allow the request. In this article, you can check the list of all HTTP headers Cloudentity expects, their descriptions, and expected values examples.

Why Headers Matter and How Reverse Proxies May Alter Them

A reverse proxy is a server that sits in front of web servers. It is responsible for intercepting and forwarding client requests (for example, browser’s request) to the web server. Once the web server responds to the proxy, the resources returned to the client appear as if they originated from the web server itself. Usually, reverse proxies are used to help with increasing security, performance, and reliability of offered services. Some of the most commonly reverse proxies include solutions offered by, for example, NGINX, Cloudflare, or Akamai.

Customers that deploy the Cloudentity platform themselves, may want to set up a reverse proxy that will sit in front of the platform and will forward client requests to Cloudentity.

[mermaid-begin]
flowchart LR consentApp[Consent Application] demoApp[Demo Application] web[Internet] proxy[Reverse Proxy] acp[Cloudentity] consentApp --> web demoApp --> web web --> proxy proxy --> acp

Because a reverse proxy intercepts and forwards the requests to the Cloudentity platform, it is critical for the proxy to correctly forward request headers to Cloudentity in order to keep all of the platform’s functionalities and features working properly. For example, some of the reverse proxies could provide Cloudentity with the IP address of the proxy itself instead of the IP address of the client requesting resources from the platform. Such practice could falsify, for example, the audit events data.

To keep Cloudentity working up to its full potential, make sure that all the headers listed in the tables below are forwarded or set properly by your reverse proxy.

Expected Custom Request Headers Reference

Header Description Expected Value
X-Forwarded-For The X-Forwarded-For request header identifies the originating IP address of a client connecting to the server through a proxy server. If not provided, the Cloudentity platform check’s the value of the X-Real-IP request header for IP address. If both headers are missing, the Cloudentity platform takes the IP address from the HTTP request’s Remote Address. Client’s IP address, for example, 10.0.0.1
X-Real-Ip For information about this header, check the description for the above X-Forwarded-For request header. Client’s IP address, for example, 10.0.0.1

Expected FAPI/Openbanking Request Headers Reference

Header Description Expected Value
x-fapi-auth-date Indicates the last time a customer logged into the client. x-fapi-auth-date: <date> where the date is supplied as a HTTP-date as defined in section 7.1.1.1 of RFC7231
x-fapi-customer-ip-address The customer’s IP address if the customer is currently logged in within the third party provider’s application. x-fapi-customer-ip-address: <ip-address>
x-fapi-interaction-id A RFC4122 UUID to the server to help correlate log entries between the client and the server. x-fapi-interaction-id: <UUID>
x-customer-user-agent Used in UK Open Banking the header indicates the user-agent the customer is using. x-customer-user-agent: <product> / <product-version> <comment>
x-jws-signature Contains a detached JWS signature of the body of the payload x-jws-signature: <jws> where the <jws> is a signature as defined in the RFC7515
x-idempotency-key Unique request identifier to support idempotency. Used in UK Open Banking x-idempotency-key: <unique-key>
x-v Used in Consumer Data Right. Version of the API end point requested by the client. Must be set to a positive integer. x-v: <version> where the version is the highest supported by the Data Holder API version between the x-min-v and x-v.