OAuth2 token validation fails when posting journal entries through REST API to our multi-tenant S/4HANA system. Single-tenant environments work fine but multi-tenant setup returns 401 Unauthorized.
We’re calling the Journal Entry API with proper OAuth2 bearer token:
POST /sap/opu/odata/sap/API_JOURNALENTRY_SRV/A_JournalEntry
Authorization: Bearer eyJhbGc...
Content-Type: application/json
Token is obtained from /oauth/token endpoint with correct client credentials and scope. Token validation succeeds in single-tenant but fails in multi-tenant with error “Invalid scope for tenant context”. We’ve configured OAuth2 scope as API_JOURNALENTRY_SRV.Create but something’s missing for multi-tenant token validation. The API gateway setup might need tenant-specific routing but documentation is unclear. How do we properly configure OAuth2 for multi-tenant journal entry posting?
Multi-tenant OAuth requires tenant ID in the token request. When you call /oauth/token, add the tenant parameter: grant_type=client_credentials&scope=API_JOURNALENTRY_SRV.Create&tenant=<tenant_id>. The tenant ID should match your system’s tenant configuration. Without it, the token is issued without tenant context and fails validation.
I think the scope definition is incomplete. For multi-tenant scenarios, the scope needs to include the tenant identifier as part of the scope string itself. Try using scope format: API_JOURNALENTRY_SRV.Create.tenant_<tenant_id>. Also verify that your OAuth client is registered as multi-tenant capable in the API gateway configuration. Single-tenant clients can’t access multi-tenant resources even with correct tokens.
The root cause involves all three configuration layers that must align for multi-tenant OAuth to work.
For OAuth2 scope configuration, the scope string in multi-tenant contexts must include tenant-aware claims. Instead of just API_JOURNALENTRY_SRV.Create, use the extended format: API_JOURNALENTRY_SRV.Create with additional tenant-specific scope suffix. However, the more critical aspect is ensuring your OAuth client registration includes the tenant scope claim in its configuration. In SAP BTP cockpit, when you recreate the OAuth client as multi-tenant, navigate to the Scopes section and explicitly add tenant_id as a custom claim. This ensures the issued token carries tenant context.
For multi-tenant token validation, the S/4HANA system must be configured to extract and validate tenant claims from incoming tokens. In transaction SOAUTH2, create a new OAuth 2.0 client profile specifically for multi-tenant access. Set the scope validation to require tenant claims. The critical configuration is in the ‘Scope Assignment’ section - map your API scope to a tenant-aware authorization object. Create authorization object Z_TENANT_API with field TENANT_ID, then assign it to your OAuth scope. This way, token validation checks not just the scope but also tenant entitlement.
For API gateway setup, this is where tenant routing happens. In your SAP API Management or Cloud Integration configuration, set up tenant-aware routing rules. The API proxy must extract tenant ID from either the token (preferred) or request header and route to the appropriate backend tenant. Configure the target endpoint template as: https://{tenant_id}.s4hana.cloud.sap/sap/opu/odata/sap/API_JOURNALENTRY_SRV. Add a policy to extract tenant_id from JWT token claims and substitute into the target URL.
Implementation steps:
-
In BTP Cockpit, recreate OAuth client:
- Select Multi-Tenant application type
- Add custom claim: tenant_id
- Configure allowed tenants list
- Generate new client credentials
-
Update token request to include tenant:
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id=<new_client_id>
&client_secret=<new_secret>
&scope=API_JOURNALENTRY_SRV.Create
&tenant=<tenant_identifier>
-
In S/4HANA transaction SOAUTH2:
- Create OAuth profile for multi-tenant
- Enable tenant claim validation
- Map scope to tenant-aware auth object
-
Configure API gateway tenant routing:
- Extract tenant_id from JWT
- Apply routing policy based on tenant
- Set tenant-specific rate limits
-
Test with decoded JWT to verify tenant claim presence:
Use jwt.io to decode your token and confirm tenant_id appears in claims section.
One additional consideration: if you’re using SAP Cloud Connector for on-premise connectivity, ensure the virtual host mapping includes tenant-specific routing. Each tenant may need its own virtual host entry with proper principal propagation configured.
After implementation, monitor the OAuth token validation logs in transaction SLG1 (application log) with object ‘SOAUTH2’. This shows exactly why tokens are rejected and helps troubleshoot tenant claim validation issues.
You need to recreate the OAuth client as multi-tenant in BTP cockpit. Single-tenant clients can’t be converted. When creating, select ‘Multi-Tenant’ option and specify allowed tenants. The tenant ID goes in the token request as a parameter, but the client must be configured to accept multi-tenant requests first. Also check destination configuration in BTP - it needs the tenant routing parameter.
Check your SAML2 configuration in transaction SAML2. Multi-tenant systems require proper tenant isolation at the SAML level. Each tenant should have its own trusted identity provider configuration. If the OAuth provider is using SAML assertions for token generation (common in cloud deployments), the assertion must include tenant claims. Without proper SAML tenant mapping, OAuth tokens won’t carry the necessary tenant context for validation.
We’re using SAP Cloud Platform for OAuth provider. I checked and our OAuth client is registered as single-tenant type. Do we need to recreate it as multi-tenant, or can we modify the existing registration? Also, where exactly do we specify the tenant ID - in the token request parameters or in the client configuration?