Authentication & Permissions

Authentication and authorization are fundamental to protecting financial data, accounts, and transactions within Infrarails.

Authentication verifies the identity of an application or client, while authorization determines which operations and resources that identity is permitted to access.

API authentication

Infrarails integrations require authorized access to the relevant API environment.

The ledger management model supports API credentials associated with client or ledger access.

The exact credential format, authentication header, provisioning process, and supported permissions are defined by the Infrarails API Reference.

Protecting API credentials

API credentials must be treated as sensitive information.

Recommended security practices include:

Store credentials in a dedicated secret-management system.
Never embed credentials in browser-side JavaScript.
Never commit credentials to source control.
Restrict credential access to authorized services.
Use separate credentials for separate environments where supported.
Rotate credentials according to your security policy.
Revoke credentials that are no longer required.
Monitor authentication failures and unusual activity.

Server-side architecture

Sensitive financial operations should be executed through a trusted application backend.

flowchart TD
    A["Client Application"] --> B["Application Backend"]
    B --> C["Authentication & Authorization"]
    C --> D["Infrarails API"]
    D --> E["Ledger Resources"]

The application backend should validate the end user's permissions before submitting operations using its own infrastructure credentials.

Authentication versus authorization

Authentication answers:

Who is making the request?

Authorization answers:

What is that identity allowed to do?

An authenticated application should not automatically be granted unrestricted access to every ledger, account, or transaction.

Resource access

Infrarails organizes accounting records using ledger identifiers.

Applications should validate the relationship between the authenticated identity and the requested ledger resources.

Access controls should prevent unauthorized operations against resources belonging to another customer, application, or accounting domain.

Least privilege

Grant each integration only the permissions necessary for its intended operations.

For example, an application that only retrieves account balances should not require permission to initiate financial transactions.

The availability of granular permission scopes depends on the implemented authorization model.

Environment separation

Production and non-production environments should use separate credentials where supported.

Applications should not reuse production credentials in development systems or expose them through testing tools.

Credential rotation

Credential rotation should be planned to minimize service disruption.

A typical process includes:

Provision a replacement credential.
Store it securely.
Update the authorized application configuration.
Verify successful authentication.
Revoke the previous credential.
Monitor for unexpected failures.

The actual rotation procedure depends on the available credential-management features.

Monitoring and auditability

Applications should maintain appropriate records of security-relevant activity, including:

Authentication failures.
Unauthorized access attempts.
Credential changes.
Sensitive configuration updates.
Financial operation requests.
Administrative actions.

Avoid logging credentials, authorization headers, or unnecessary sensitive customer information.

Best practices

Keep financial API credentials server-side.
Enforce authorization in your application backend.
Validate resource ownership and ledger scope.
Apply least-privilege access.
Separate environments and credentials.
Protect sensitive information in logs.
Rotate and revoke credentials when required.
Review access permissions regularly.

Next steps

Continue with Idempotency to understand duplicate prevention for financial oper