Security

Security model

Riversoft® STCP DirectLink applies managed file transfer (MFT) controls to every protocol and connector: only authenticated users exchange files, data travels encrypted, every operation is validated against the user’s rules and everything is recorded. Security is organized in layers:

Protocols and connectors

Riversoft® STCP DirectLink protocols and connectors use encrypted connections and per-user authentication. Mechanisms vary according to the protocol and the environment’s security policies.

TLS 1.2 and TLS 1.3

The portal, the REST API, AS2, Webhook, FTPS and the cloud connectors (Amazon S3, Azure Blob Storage, Google Cloud Storage and Oracle Cloud Object Storage) use TLS 1.2 or TLS 1.3.

SFTP

SFTP (SSH File Transfer Protocol) uses a secure SSH-2 channel. Authentication can use a user name and password or a public/private key pair. The algorithms and security policies are negotiated when the connection is established.

The SFTP Server accepts two-factor authentication (2FA) and MFA, according to the user configuration.

AS2

AS2 (Applicability Statement 2) is designed for document exchange between organizations. It uses TLS 1.2 and 1.3, X.509 certificates, S/MIME, digital signatures, MDN (Message Disposition Notification) and MIC (Message Integrity Check).

• The MDN proves message delivery and can be synchronous or asynchronous, with a digital signature.
• The combination of MIC and digital signature provides non-repudiation of sending and receipt.
• EDI, EDIFACT, X12, XML, JSON, binary files and other content types are supported.
• The MDN can be encrypted when sent and received, according to the user configuration.
• The user can authenticate to the AS2 service with a Bearer token.

FTPS, Webhook and cloud storage

Riversoft STCP DirectLink Portal authentication

Users can access the portal:

• Directly, with their STCP user name and password. When required by the configuration, sign-in is completed with a second factor (MFA): a PIN sent by email or SMS, or a TOTP code from an authenticator app.
• Through SSO (Single Sign-On), with Google, Microsoft, Apple or any identity provider compatible with OAuth 2.0 and 2.1/OpenID Connect or SAML 2.0.

After sign-in, the session is kept by the __Host-dirl_session cookie, issued with the HttpOnly, Secure and SameSite=Strict attributes. Signing out removes the cookie. For this reason, the portal must be published over HTTPS.

Protection against automation

The administrator can enable Cloudflare Turnstile on sign-in, first access and password recovery. When enabled, the portal shows the Cloudflare challenge before sending the credentials, and the request is processed only with a valid token. The token is single-use and expires in 300 seconds. Integrations that call these routes directly must follow the API contract.

API authentication

Starting with version 9, protected API routes (upload, listings, report and sign-out) accept only a Bearer token. Basic authentication (user name and password) is accepted only at sign-in.

When both the Authorization header and the cookie are present, the header takes precedence. The token expires after the time given in expires_in.

The token authenticates the user, but does not grant access on its own: the API also applies the user’s rules on the STCP server (connection enabled, time window, filters and session limit). For this reason, a valid token can receive 403.

Impersonation token

Technical integrations that need a long-lived credential can use an impersonation token, generated by the administrator in the supervision interface. The token carries a session identifier registered for the user; the API checks this identifier on every call, and a token whose identifier is not registered is rejected. Details in OAuth tokens.

The API can follow OAuth 2.1. See OAuth 2.1 compatibility.

Trusted JWT authentication

To integrate Riversoft STCP DirectLink with service portals, the portal issues a JWT for the user, signed with its private key, and exchanges it for a Riversoft STCP DirectLink Bearer token (token exchange, RFC 8693). Riversoft STCP DirectLink validates the source JWT with the JWT provider configuration registered by the administrator.

    sequenceDiagram
    autonumber
    participant PS as Service portal
    participant DL as Riversoft STCP DirectLink API
    PS->>PS: Issues the user JWT (private key)
    PS->>DL: POST /auth/token (token exchange, subject_token = JWT, provider)
    DL->>DL: Validates signature, issuer, audience and validity
    DL->>DL: Checks the user and the access rules
    DL-->>PS: access_token (Bearer)
    PS->>DL: Calls to protected routes with Authorization: Bearer
  

Token exchange request

curl -X POST "https://<domain>/directlink/v2/auth/token" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:jwt" \
  --data-urlencode "subject_token=<source-jwt>" \
  --data-urlencode "provider=<jwt-provider>"

• provider is the identifier of the JWT provider registered by the administrator. It can also be sent in the X-STCPDIRECTLINK-JWT-ISSUER header; if both are sent, the form field takes precedence. The value does not need to match the iss claim.
• The only accepted subject_token_type is urn:ietf:params:oauth:token-type:jwt.
• The user identified in the claims must exist on the STCP server and match the configured profile.

Source token structure

Header

Payload (claims)

The public key (or validation material) that checks the signature is registered by the administrator in the JWT provider configuration. The kid and alg fields must match those of the registered key. Protect the service portal’s private key.

Secure link and security code

The secure link sent to external recipients identifies the email address or mobile number linked to the file. The download is released only with the security code (PIN), which is sent only to that email address or mobile number. See the flow in Concepts and architecture.

The validity is set by the administrator:

Password management

The user sets or resets the password in two steps:

1. Request the change link through First access or Forgot password.
2. Confirm the new password through Password change, with the security PIN sent to the registered email address.

Password encryption key

Passwords stored in the configuration database are encrypted with a key that must be the same in all modules of the environment. See how to set the key and what to do to change it in Configuration: password encryption key.

Best practices

• Publish Riversoft STCP DirectLink over HTTPS only (the session cookie requires Secure).
• In integrations, obtain the token once and reuse it until it expires; do not send the password on every call.
• Store tokens, including impersonation tokens, in a secrets vault and define their rotation.
• Enable only the authentication modes the environment needs.
• Consider enabling Cloudflare Turnstile on sign-in, first access and password recovery.
• Implement rate limiting on the edge firewall: the API does not enforce it.
• Use the file’s SHA-256 hash (h or X-STCPDIRECTLINK-HASH) to validate upload integrity.
• Protect the private key used to sign the source JWTs.
• Use the same encryption key (applConfigPassPhrase) in all modules of the environment. See Password encryption key.

Privacy

The Riversoft STCP DirectLink portal uses only the __Host-dirl_session session cookie, required to keep the user signed in, and does not use tracking cookies. The cookie is removed at sign-out.

When Cloudflare Turnstile is enabled, the challenge is verified by Cloudflare, which receives the challenge token and the user’s IP address.