XSUAA, OAuth 2.0, Scopes and JWT-Based Application Authorization (Part 3)

📌 KEY POINTS
✅ A valid JWT proves identity/scopes for THAT service — not unrestricted access to downstream S/4HANA.
⚠️ Never decode a JWT and trust its contents without cryptographic validation. Never log complete production tokens — they're bearer credentials.
💡 Client credentials represent the client application, not a business user — don't use them where user identity/authorization is actually required.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE FLOW

• Applications define authorization scopes and role templates
• Users/clients authenticate via OAuth/OIDC, receive signed access tokens (commonly JWTs)
• Token carries issuer, subject/client, audience, granted scope/role
• App/framework validates signature, issuer/audience/expiry, then enforces required scopes

━━━━━━━━━━━━━━━━━━━━
▶ 2. ROLE COLLECTIONS → SCOPES

• Human role-collection assignments translate into the scopes reflected in issued tokens
• Client-credentials flow represents the client app itself, for service-to-service calls — not a business user

━━━━━━━━━━━━━━━━━━━━
⚠️ 3. HANDLING RULES

• Never decode-and-trust a JWT without cryptographic validation
• Never log complete production tokens — they are bearer credentials
• Troubleshoot with sanitized claims only: issuer, audience, subject/client, scopes, expiry, plus app binding and trust config

━━━━━━━━━━━━━━━━━━━━
▶ 4. THE LAST MILE

• A valid token proves identity/scopes for that one service — authorization must still exist in the backend application for downstream access

✅ CHECKPOINT: explain why a valid JWT for one service doesn't mean unrestricted downstream access.

An API returned 403 although login succeeded. The JWT was valid but lacked the application's Write scope because the user's role collection contained only the Viewer role. Security fixed the role assignment; changing OAuth client secrets or S/4 roles would not have solved the BTP application authorization.

• Treating a valid JWT as proof the user is authorized for every operation.
• Trusting decoded token claims without signature/audience validation.
• Logging full bearer tokens.
• Using client credentials when end-user identity must be propagated.
• Mixing BTP application scopes with downstream S/4 authorizations.

• Define narrow business scopes.
• Validate token signature, issuer, audience and expiry.
• Never log bearer tokens.
• Choose OAuth flow according to identity requirement.
• Enforce authorization again at downstream boundaries.

Explain scopes, role templates/collections and JWT validation, then contrast user-token and client-credentials scenarios. Strong answers mention issuer/audience/expiry validation and downstream authorization separation.