BTP & Integrationadvanced

BTP API Management Part 4: Security — API Keys, OAuth 2.0, JWT and mTLS

Key takeaway

Secure APIs properly: API keys for identification (not strong authentication), OAuth 2. 0 client credentials and token verification, JWT verification against an identity provider (issuer, audience, signature), mutual TLS for partner-level trust, and securing the proxy-to-back-end leg.

Explanation

📌 KEY POINTS
✅ API keys identify applications; combine with stronger auth for sensitive APIs.
✅ OAuth 2.0 tokens (issued by APIM or an IdP) are verified per call; scopes restrict operations.
✅ JWT verification must check signature, issuer, audience and expiry — not just "is it a JWT".
✅ mTLS authenticates partner systems by certificate at transport level.
⚠️ Accepting a valid JWT without checking audience lets tokens for other APIs call yours.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 designed chains. Now security in depth.

━━━━━━━━━━━━━━━━━━━━
▶ 1. API KEYS

Identification, analytics, quotas.

━━━━━━━━━━━━━━━━━━━━
▶ 2. OAUTH 2.0

Client credentials; token verification; scopes.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. JWT\n• Signature, issuer, audience, expiry.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 4. mTLS\n• Client certificates for partners.

━━━━━━━━━━━━━━━━━━━━
▶ 5. BACK-END LEG

Credentials in KVM; OAuth or certificates to back end.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Protect an API with OAuth client credentials.
Add JWT audience validation for IdP tokens.
Configure mTLS for one partner.

✅ CHECKPOINT: tokens for another audience are rejected.

Code example

ABAP Code

===== POLICIES =====VerifyAPIKey: <APIKey ref="request.header.APIKey"/>OAuthV2 VerifyAccessToken: scopes "orders.read"Verify JWT (IdP tokens): issuer https://<ias>.accounts.ondemand.com, audience <client-id>, JWKS URL for signaturemTLS: virtual host with client certificate validation (partner CA) ===== SECURITY LEVELS =====Public read-only: API key + quota | Partner: OAuth/mTLS + quota | Internal user: JWT from IAS + scopes

Real project scenario

A partner API accepted any valid JWT from the corporate IdP, including tokens issued for other apps. Adding audience and scope checks restricted access to intended clients.

Common mistakes

Keys as sole auth for sensitive APIs.
No audience checks.
Forwarding keys to back end.
Secrets in policies.
One level for all APIs.

Best practices

Layered auth.
Full JWT validation.
Separate back-end auth.
KVM for secrets.
Security levels per API.

Interview angle

Questions: "API key vs OAuth?", "What must JWT verification check?", "When use mTLS?"
Strong answer: keys, OAuth, JWT checks, mTLS, back-end leg.

Practice this lesson

Quick check

1. When the VerifyOAuthV2 policy is attached to an API proxy, what does it primarily do?

2. What does the VerifyAPIKey policy accomplish when attached to an API proxy's request flow?

3. A partner API accepted a valid corporate JWT issued for a different app. What check was missing?

Interview questions

1. A production issue is reported in API Management. What would you check first, and how would you troubleshoot it systematically?

Answer it in your own words first, then compare.

2. Define API security for public, partner and internal-user APIs in API Management.