Please note: For reasons of simplification, some of the following requirements that refer to “services” apply to all implementation variants such as XML WebServices or REST APIs.
External services SHOULD only be made available externally using a hardened Service/API Gateway.
The strength of the authentication mechanism used MUST be adequate to the protection needs.
Shared secrets used for services authentication (e.g. API keys or OAuth 2.0 Client Secrets) MUST have the following characteristics:
Length min 32 characters (= 256 bit)
Cryptographically random (consisting of alpha-numeric and special characters)
Stored securely according to the requirements specified in
Transmitted outside of URLs (e.g. via HTTP POST or HTTP header).
For assurance class >= HIGH, external service-to-service communication SHOULD be authenticated using asymmetric cryptography (e.g. X.509 certificates or signed JWT access tokens).
Authentication credentials MUST be unique for different systems and environments (e.g. test, production).
Services with assurance class >= HIGH SHOULD be protected using Access Tokens (OAuth 2.0 or SAML)
Following requirements do apply to access tokens:
Transmitted only via HTTPS
Issued by a trusted and hardened server (e.g. OIDC Identity Server or OAuth 2.0 Authorization Server)
created and validated using mature APIs
OAuth 2.0/OICD requirements:
Only 3-Legged: Authorization Code Grant with PKCE (or alternative authorization code binding technique, e.g. “state” binding or OICD Nounces) for both public clients (e.g. single-page applications (SPAs) SHOULD be used for both public and confidential clients (e.g. server-side web apps).
Only 3-Legged: For CSRF protection, Authorization Code Grant Flows MUST either use the “state” parameter, PKCE, or “OICD Nounces
Only 3-Legged: Clients MUST register (and be validated using) full redirect URI as described in RFC 6819 Section 22.214.171.124 (no pattern matching).
Service-to-service access SHOULD be protected using Client Credential Grant.
HTTPS MUST be used for all communication.
See requirements for Access Tokens above.
Web UI APIs:
MUST implement the same security requirements for access to external resources as the corresponding web UI (authentication, validation, etc.).
MUST contain CSRF protection if working in user context (see section https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/1179649/8.10+Hardening+of+Session+Management).
Cross-domain requests MUST be performed using secure mechanisms such as Cross-Origin Resource Sharing (CORS) and a restrictive policy (e.g. restricted so certain hosts or domains or with credential submission deactivated).
The origin header of cross-domain requests MUST be authorized on the server-side.
Services SHOULD implement restrictive limits (max. requests per client or time interval).
WebSockets MUST transfer all confidential data with
wss:// schema and an additional server-side authorization of the source origin header.
 See https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-00
 See https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14