# Authentication When calling the integration interfaces described in this section, Amiko needs to authenticate against these APIs. For this Amiko sends a signed JSON Web Token (JWT) as Access Token in the HTTP request header. JWT is the de facto standard for API authentication tokens, is used in OAuth2/OIDC flows and typically well supported by API gateways and reverse proxies. Also for machine to machine authentication RSA-signed JWTs are a good way of performing strong authentication while also providing additional information in the payload of the token (JWT claims). This, combined with easier debugging, makes it superior to Client TLS Authentication (aka Mutual TLS). ## RSA Key Generation The RSA key pair is generated by the Issuer using existing systems and procedures. The public key has to be loaded into the API access infrastructure (e.g. API gateway) that protects the Issuer integration interfaces. The private key is loaded, together with other keys and configuration, into the Edge Connector by the Issuers IT operation staff. This leaves the API authentication in full control of the Issuer and no private key as to be provided to Rivero staff. ## Header HTTP Authorization header using the Bearer authentication scheme. Example: ``` GET /resource HTTP/1.1 Host: amiko.bank.com Authorization: Bearer ``` ## JWT Content Amiko produces and sends the following content ### Header ``` { "type": "JWT", "alg": "RS256" //RSA Signature with SHA-256 } ``` ### Payload ``` { "iat": 1527809373, //JWT creation timestamp "exp": 1527812973, //IAT + allowed expiration "sub": "", //Subject: typically the account/key identifier "iss": "", //Issuer: OPTIONAL (if gateway expects a value, defaults to "amiko" if none is specified) "aud": "", //Audience: OPTIONAL (if gateway expects a value) } ``` The allowed expiration time (e.g. 1 hour) and subject string have to be provided as part of the Edge Connector configuration. If additional claims are required by the API gateway on Issuer Bank's side, then these have to be provided as key-value pairs in the Edge Connector configuration as well. ## Mutual TLS & optional API Key If the Issuer Bank can’t handle JWT-based authentication, Amiko also supports Client TLS Authentication (aka Mutual TLS) to authenticate against the integration APIs. The needed keys and keyfile has to be provided by the Issuer Bank and configured as part of the Edge Connector configuration. Optional it can be combined with an API key. see [Provisioning Keystores](/amiko-documentation/JL6JD0mRhH1awRHP2Gz0/deployment-and-operations/edge-connector/provisioning-keystores.md) ## API Key There is also the option to authenticate with an API Key only. The API key has to be provided by the Issuer Bank. The key itself and name of the request header that must contain the API key, have to be provided as part of Edge Connector configuration. ## OAuth 2.0 Client Credentials Flow We are sending a URL-encoded form to the OAuth provider, containing the following fields: * **client\_id**: Provided by the OAuth provider. * **client\_secret**: Provided by the OAuth provider. * **audience**: Determined from the configuration. * **grant\_type**: Set to `client_credentials`. Note that we are not utilising "refresh tokens" in this process. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://rivero.gitbook.io/amiko-documentation/JL6JD0mRhH1awRHP2Gz0/development/issuer-integration-api/authentication.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.