Supplier collaboration API security: best practices for third-party access and data protection

We’re opening up our SAP PLM 2020 supplier collaboration APIs to external partners and need to implement robust security controls. I’m evaluating authentication and authorization strategies for third-party access while protecting sensitive product data.

The main concerns are: implementing OAuth2 or SAML authentication for supplier identity management, designing role-based authorization that limits suppliers to only their relevant parts and BOMs, and masking sensitive data like cost information or proprietary specifications in API responses.

I’ve seen implementations that use API gateway layers to handle authentication and data filtering before requests reach SAP, while others rely on SAP’s native security model. What are the best practices for OAuth2/SAML authentication with external suppliers? How do you implement role-based authorization that’s granular enough to limit supplier access to specific projects or part families? And what’s the most effective approach for sensitive data masking in API responses - gateway-level filtering or SAP-level field permissions?

We use OAuth2 with supplier-specific client credentials for authentication. Each supplier gets a unique client ID and secret, and we issue short-lived access tokens with 1-hour expiration. The OAuth flow runs through our API gateway which validates tokens before forwarding requests to SAP. This keeps supplier credentials out of SAP entirely and gives us centralized token management. For authorization, we map OAuth scopes to SAP roles, so a supplier’s token includes scopes like ‘read:parts:project-alpha’ which maps to specific SAP authorization objects.

SAML federation works well if your suppliers already have identity providers. We federate with large suppliers who have their own SAML IDPs, which means their employees can access our APIs using their corporate credentials. For smaller suppliers without SAML capability, we fall back to OAuth2 client credentials. The key is having an API gateway that supports both authentication methods and can map external identities to internal authorization policies consistently. We use Azure API Management which handles both SAML and OAuth2 natively.

For sensitive data masking, gateway-level filtering is more flexible than SAP field permissions. We define data sensitivity policies in our API gateway configuration that specify which fields to mask or remove based on the caller’s role. Cost fields, internal notes, and proprietary specifications are automatically filtered from API responses to suppliers. The advantage of gateway-level masking is that we can update policies without changing SAP configuration, and we can implement complex masking rules like showing partial data or redacted values rather than just hiding fields entirely.