We’re experiencing persistent 401 Unauthorized errors when attempting to post journal entries to our SBOM management service via REST API. The integration was working fine in our single-tenant test environment, but fails in our multi-tenant production setup.
The OAuth2 token is being generated successfully, but validation fails at the API gateway level. We’ve verified the token contains the required scopes (sbom:write, journal:create), but the gateway rejects it immediately.
This is blocking our financial data synchronization across regional instances. Has anyone dealt with OAuth2 scope configuration or multi-tenant token validation issues in SAP PLM 2020? We need to understand the proper API gateway setup for multi-tenant environments.
Let me provide a comprehensive solution addressing all three focus areas:
OAuth2 Scope Configuration:
Your scopes are correct (sbom:write, journal:create), but you need to register your client application with multi-tenant support. Update your OAuth2 client registration:
Multi-Tenant Token Validation:
The critical issue is your token structure. Multi-tenant tokens in SAP PLM 2020 require specific claims. Your token payload should include:
Standard scopes (sbom:write, journal:create)
tenant_id claim at root level
tenant_context object with region and instance metadata
Switch to the multi-tenant token endpoint: /oauth2/tenant/{tenant-id}/token. This endpoint automatically injects tenant claims into the JWT. You’ll need to pass the tenant ID as a path parameter during token acquisition.
API Gateway Setup:
Your gateway needs three configuration updates:
Enable TenantResolver in the security filter chain (application.yml):
Update routing rules to include tenant context headers. The gateway must extract tenant_id from the validated token and add it as X-Tenant-Context header before forwarding to SBOM service.
The SBOM service itself also needs tenant-aware configuration. Verify that sbom.multi-tenant.enabled=true is set in the service properties. Without this, even properly validated requests will fail at the service layer.
After implementing these changes, your authentication flow will be: Client requests token from multi-tenant endpoint → Token includes tenant claims → Gateway validates token AND tenant context → Gateway adds tenant header → SBOM service validates tenant header → Request succeeds.
Test with a simple GET request first to verify the authentication chain before attempting POST operations. The 401 error should resolve once all three layers are properly configured for multi-tenant operation.
This draft is based on general SAP PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen similar issues with multi-tenant OAuth2 setups. The token might be valid but missing tenant-specific claims. Check if your token includes the tenant_id claim and whether your API gateway is configured to validate it. In SAP PLM 2020, the gateway expects both the standard OAuth2 scopes AND tenant context in the JWT payload. You might need to update your token endpoint configuration to include tenant information in the token generation flow.
Are you using the correct token endpoint for multi-tenant environments? SAP PLM 2020 has separate endpoints for single vs multi-tenant OAuth flows. The multi-tenant endpoint is typically /oauth2/tenant/{tenant-id}/token instead of the standard /oauth2/token. Also verify that your client application is registered in each tenant’s OAuth configuration. The 401 error you’re seeing is classic multi-tenant scope validation failure.
Check your API gateway routing rules. In multi-tenant setups, the gateway needs to extract tenant context from either the token or request headers before forwarding to the SBOM service. We had a similar issue where the gateway was configured for single-tenant validation rules. You need to enable tenant-aware token validation in the gateway configuration. Look at the gateway’s security policy settings - there should be a multi-tenant validation module that needs to be activated.
Thanks for the suggestions. I checked our token endpoint and we ARE using the single-tenant endpoint. That’s likely part of the problem. However, I’m also concerned about the scope configuration. When I decode our JWT token, I see the scopes are there but they’re not prefixed with the tenant ID. Should they be formatted as tenant123.sbom:write instead of just sbom:write? Also, our API gateway logs show “scope validation passed” but then “tenant context missing” - which suggests the gateway itself might need additional configuration beyond just the token format.
The tenant context issue is separate from scope formatting. Your scopes should remain as sbom:write, but the token needs an additional tenant_id claim at the root level of the JWT. However, the bigger issue is your API gateway configuration. You need to enable the TenantResolver module in the gateway’s security chain. This module extracts tenant context and validates it against the token’s tenant_id claim. Without this, even valid multi-tenant tokens will be rejected. Check your gateway’s application.properties for tenant.validation.enabled setting.
I worked through this exact scenario last quarter. The issue spans multiple layers. Your OAuth2 client registration needs to specify grant_type=client_credentials with tenant_context=true parameter. This ensures tokens include tenant metadata. Beyond that, verify your SBOM service itself is configured to accept multi-tenant requests - there’s a service-level tenant validation that happens AFTER gateway validation.