SAP Commerce OCC Authentication & OAuth 2.0 Explained: Complete Guide with Postman

Introduction

Security is one of the most important aspects of SAP Commerce OCC Web Services.

In a real-world eCommerce application, APIs cannot simply be exposed to every client.

For example, an API such as:

GET /occ/v2/electronics/users/current/orders

contains customer-specific information and must be protected.

SAP Commerce uses OAuth 2.0 as the standard authorization framework for OCC Web Services. OCC security is implemented using configurable Spring Security mechanisms, with authentication and authorization applied to determine whether a client or user can access a particular resource.

In this article, we will understand:

• What OAuth 2.0 is
• Authentication vs authorization
• OCC security architecture
• OAuth clients
• Access tokens
• JWT tokens
• Client Credentials flow
• Authorization Code flow
• PKCE
• Anonymous vs authenticated OCC APIs
• 401 vs 403
• Postman testing
• Common OCC security problems
• SAP Commerce interview questions

---

1. What is OAuth 2.0?

OAuth 2.0 is an authorization framework that allows applications to access protected resources without requiring the client application to directly handle the user's credentials.

In SAP Commerce, OAuth is used to secure OCC APIs.

A simplified flow looks like:

Client Application
       |
       | Request access token
       ↓
Authorization Server
       |
       | Access Token
       ↓
Client Application
       |
       | Authorization: Bearer <token>
       ↓
OCC API
       |
       ↓
Resource Server
       |
       ↓
Protected Resource

SAP Commerce Cloud documents OAuth as the default authorization framework for commerce-driven OCC Web Services.

---

2. Authentication vs Authorization

This is one of the most common interview questions.

Authentication

Authentication answers:

Who are you?

For example:

Username
Password
OAuth token

The system verifies the identity.

---

Authorization

Authorization answers:

What are you allowed to do?

For example:

Customer
    ↓
Can view own orders

Client
    ↓
Can access allowed APIs

Admin
    ↓
Can perform administrative operations

A simple way to remember:

Authentication = Who are you?

Authorization = What can you do?

SAP Commerce OCC security separates these concepts and uses roles and other constraints to determine access.

---

3. OCC Security Architecture

A simplified architecture is:

                 CLIENT
                    |
                    |
             OAuth Access Token
                    |
                    ↓
          ┌──────────────────┐
          │  OCC Web Layer   │
          └────────┬─────────┘
                   |
                   ↓
          ┌──────────────────┐
          │ Spring Security  │
          └────────┬─────────┘
                   |
             Authentication
                   |
                   ↓
             Authorization
                   |
                   ↓
          ┌──────────────────┐
          │ OCC Controller   │
          └────────┬─────────┘
                   |
                   ↓
                Facade
                   |
                   ↓
                Service
                   |
                   ↓
                 DAO

The important point is:

Security is checked before the request reaches your business logic.

---

4. What is an OAuth Client?

An OAuth client represents an application requesting access to protected resources.

For example:

Mobile Application
Web Application
Integration System
Third-Party Application
Backend Service

The client is normally identified using:

client_id
client_secret

For example:

client_id = mobile_app
client_secret = ********

The secret should never be exposed in client-side code.

---

5. What is an Access Token?

An access token represents authorization granted to a client.

After successfully authenticating with the authorization server, the client receives a token.

The client then sends:

Authorization: Bearer <access-token>

with subsequent API requests.

Conceptually:

Client
  |
  | client credentials
  ↓
Authorization Server
  |
  | access token
  ↓
Client
  |
  | Bearer token
  ↓
OCC API

---

6. JWT Access Tokens

For current SAP Commerce Cloud OAuth support using JDK 21, SAP documents JWT access tokens.

JWT stands for:

JSON Web Token

A JWT is a self-contained token containing claims about the authorization.

A simplified JWT looks like:

xxxxx.yyyyy.zzzzz

It consists of:

Header
.
Payload
.
Signature

For example:

{
  "sub": "customer@example.com",
  "roles": [
    "CUSTOMERGROUP"
  ],
  "exp": 1780000000
}

The actual claims depend on the SAP Commerce configuration.

SAP documents that current JDK 21 OAuth support uses JWTs for access-token management and that the resource server validates the JWT signature using public keys available through a JWKS endpoint.

---

7. JWT Authentication Flow

The current flow can be visualized as:

                 Client
                   |
                   | 1. Request Token
                   ↓
          Authorization Server
                   |
                   | 2. Signed JWT
                   ↓
                 Client
                   |
                   | 3. API Request
                   | Authorization: Bearer JWT
                   ↓
           OCC Resource Server
                   |
                   | 4. Verify JWT
                   ↓
              OCC Endpoint

The resource server can validate the JWT signature using the authorization server's public keys.

This means the resource server does not have to perform a database lookup for every JWT validation.

---

8. OAuth Grant Types

OAuth supports different authorization flows.

For SAP Commerce, the flow you should understand depends on your Commerce version and security configuration.

For modern JDK 21-based SAP Commerce Cloud OAuth, the important flows are:

Client Credentials
Authorization Code

The rebuilt OAuth implementation removed the older:

Resource Owner Password
Implicit

flows because they are deprecated/discouraged by current OAuth security practices.

This version distinction is important when working with older SAP Commerce projects.

---

9. Client Credentials Flow

The Client Credentials flow is useful when:

An application needs to access resources on its own behalf.

There is no end-user involved.

Example:

Integration System
       |
       ↓
SAP Commerce OCC

Possible use cases:

• Backend integration
• ERP integration
• Middleware
• Scheduled integration
• Server-to-server communication

---

10. Client Credentials Flow Diagram

Integration Application
          |
          | client_id
          | client_secret
          ↓
Authorization Server
          |
          | access_token
          ↓
Integration Application
          |
          | Bearer token
          ↓
OCC API

---

11. Client Credentials Request

A typical token request looks conceptually like:

POST /authorizationserver/oauth/token
Content-Type: application/x-www-form-urlencoded

Request:

grant_type=client_credentials
client_id=my-client
client_secret=my-secret

The exact endpoint and configuration can vary by SAP Commerce version and deployment.

SAP's OAuth documentation provides the Client Credentials flow as the mechanism for giving a client access to resources it owns.

---

12. Example Token Response

A token response may look like:

{
    "access_token": "eyJhbGciOi...",
    "token_type": "Bearer",
    "expires_in": 3600
}

The client then uses:

Authorization: Bearer eyJhbGciOi...

for protected API calls.

---

13. Authorization Code Flow

The Authorization Code flow is designed for applications where a user is involved.

For example:

Customer
   ↓
Web Application
   ↓
SAP Commerce

The application redirects the user to the authorization server.

The user authenticates and grants access.

The authorization server returns an authorization code.

The application exchanges that code for tokens.

---

14. Authorization Code Flow

The simplified flow is:

User
 |
 ↓
Client Application
 |
 | Authorization Request
 ↓
Authorization Server
 |
 | Login / Consent
 ↓
User
 |
 | Authentication
 ↓
Authorization Server
 |
 | Authorization Code
 ↓
Client Application
 |
 | Exchange Code
 ↓
Authorization Server
 |
 | Access Token
 ↓
Client Application
 |
 | Bearer Token
 ↓
OCC API

SAP documents the Authorization Code flow as a secure method where the user is redirected to the authorization server and the resulting authorization code is exchanged for an access token.

---

15. PKCE

PKCE stands for:

Proof Key for Code Exchange

It improves the security of the Authorization Code flow, particularly for public clients such as native applications and single-page applications.

The flow uses:

code_verifier
      ↓
code_challenge

The client creates a random:

code_verifier

and derives:

code_challenge

from it.

The authorization request includes:

code_challenge
code_challenge_method=S256

The token request later includes:

code_verifier

SAP's current Authorization Code documentation states that PKCE supports the S256 code challenge method.

---

16. Why PKCE is Important

Imagine a malicious application intercepts an authorization code.

Without PKCE, it may attempt to exchange that code.

With PKCE:

Authorization Code
        +
Code Verifier
        ↓
Token

The attacker doesn't possess the original verifier.

Therefore, the stolen authorization code is much less useful.

---

17. Anonymous OCC Requests

Not every OCC API requires a customer login.

Some APIs can be accessed anonymously depending on the endpoint and configuration.

For example, public catalog information may be available without a customer token.

Conceptually:

Anonymous User
      |
      ↓
Public OCC API
      |
      ↓
Product/Catalog Data

However:

Anonymous does not automatically mean completely unsecured.

Security configuration still applies.

SAP documents different OCC roles including ANONYMOUS, client roles, customer roles and guest roles.

---

18. Customer Authentication

A registered customer can authenticate and receive an access token.

Then:

GET /occ/v2/electronics/users/current/orders

can use:

Authorization: Bearer <customer-token>

The special:

current

identifier represents the user associated with the OAuth token in OCC APIs.

SAP's OCC documentation explicitly describes current as representing the user associated with the OAuth token.

---

19. Client vs Customer

This is important.

Client

Represents an application.

Example:

Mobile Application
Integration System
Backend Service

Customer

Represents an actual shopper.

Example:

john@example.com

So:

Client
   ↓
Application identity

Customer
   ↓
User identity

---

20. OCC Roles

SAP Commerce OCC security uses roles to determine access.

Common conceptual roles include:

ANONYMOUS
CLIENT
TRUSTED_CLIENT
CUSTOMERGROUP
CUSTOMERMANAGERGROUP
GUEST

The exact roles and configuration depend on the Commerce version and project.

SAP documents that OAuth-authenticated clients can be assigned client roles and customer authentication can result in customer roles.

---

21. 401 Unauthorized

One of the most common errors when testing OCC APIs is:

401 Unauthorized

This generally indicates an authentication problem.

Possible reasons:

Missing token
Invalid token
Expired token
Invalid client credentials
Invalid authentication configuration

Example:

GET /occ/v2/electronics/users/current/orders

without a token may result in:

401 Unauthorized

---

22. 403 Forbidden

Now consider:

403 Forbidden

This is different.

The user/client may have been authenticated successfully, but does not have permission to perform the requested operation.

Think:

401 → Who are you?

403 → I know who you are, but you're not allowed.

This distinction is extremely important during troubleshooting.

---

23. 401 vs 403

HTTP Status	Meaning
400	Invalid request
401	Authentication failed/missing
403	Authenticated but not authorized
404	Resource not found
500	Server-side error

A simple interview answer:

401 is primarily an authentication problem, while 403 indicates that the request has been authenticated but access is denied.

---

24. Testing OCC Authentication Using Postman

Postman is extremely useful for testing SAP Commerce OCC APIs.

Create a collection:

SAP Commerce OCC
│
├── Authentication
│
├── Products
│
├── Cart
│
├── Orders
│
└── Customers

---

25. Step 1 — Generate Token

Create:

POST

to your configured authorization server token endpoint.

For example:

https://localhost:9002/authorizationserver/oauth/token

The exact endpoint depends on your Commerce version and configuration.

Use:

Content-Type:
application/x-www-form-urlencoded

---

26. Step 2 — Send Credentials

For Client Credentials:

grant_type=client_credentials
client_id=<client-id>
client_secret=<client-secret>

Your configured client must have appropriate roles/access.

---

27. Step 3 — Copy the Token

The authorization server returns an access token.

For example:

{
    "access_token": "eyJhbGciOi...",
    "token_type": "Bearer",
    "expires_in": 3600
}

Copy:

access_token

---

28. Step 4 — Call OCC API

Now call:

GET /occ/v2/electronics/products/P100

Headers:

Authorization: Bearer <access-token>

Example:

Authorization:
Bearer eyJhbGciOi...

---

29. Postman Authorization Tab

Instead of manually creating the header, you can use:

Authorization
     ↓
Type: Bearer Token
     ↓
Token: <access-token>

Postman automatically generates:

Authorization: Bearer <token>

---

30. Testing an Anonymous API

For a public API, you may be able to call:

GET /occ/v2/electronics/products/P100

without:

Authorization

However, this depends on your endpoint's security configuration.

Don't assume every GET endpoint is public.

---

31. Securing a Custom OCC API

Suppose yesterday we created:

GET /occ/v2/electronics/customproducts/P100

Now we want only authenticated customers to access it.

The flow becomes:

Client
   |
   | OAuth token
   ↓
Spring Security
   |
   | Authentication
   ↓
Authorization
   |
   | Allowed
   ↓
CustomProductController

Security should be configured at the appropriate OCC/Spring Security layer rather than manually checking tokens inside the controller.

---

32. Don't Validate Tokens Manually

Avoid code like:

if (token.equals("some-token"))
{
    // allow access
}

This is completely wrong for a production application.

Authentication should be handled by the configured security framework.

Your controller should focus on business functionality.

---

33. Security Configuration

SAP Commerce OCC security is highly configurable through Spring Security.

Depending on the Commerce version, relevant security configuration is located in the webservices/OCC security configuration.

SAP documents security configuration for OCC through Spring Security and separate security configuration for OCC web-service versions.

The important conceptual architecture is:

HTTP Request
      ↓
Security Filter
      ↓
Authentication
      ↓
Authorization
      ↓
Controller

---

34. Current vs Older SAP Commerce OAuth

This is particularly important if you work on multiple SAP Commerce projects.

Older Commerce versions may use the older OAuth implementation and may document flows such as:

Password
Client Credentials
Authorization Code
Implicit

However, SAP's rebuilt OAuth capability uses current Spring Security support.

For the JDK 21 implementation, SAP documents:

Authorization Code
Client Credentials

and JWT-based access tokens.

The older Password and Implicit flows were removed from the rebuilt implementation.

Therefore, always check the exact SAP Commerce release before copying OAuth configuration from another project.

---

35. Why This Matters in Real Projects

Suppose you join a project using:

SAP Commerce 2211

and another developer gives you OAuth configuration from an older project.

You may see:

Password Grant

and:

Implicit Grant

You should not blindly copy it.

First check:

SAP Commerce version
JDK version
OAuth implementation
Spring Security version
Cloud vs on-premise

Security configuration is one area where version differences matter significantly.

---

36. Common OAuth Problems

Problem 1 — Invalid Client

You receive something similar to:

invalid_client

Check:

client_id
client_secret
client configuration
client authentication method

---

Problem 2 — Invalid Grant

Check:

grant_type

and verify that the configured OAuth client supports the requested flow.

---

Problem 3 — 401 from OCC

Check:

Authorization header
Token expiration
Token signature
Client configuration
OAuth configuration

---

Problem 4 — 403 from OCC

Check:

User roles
Client roles
Endpoint security
Authorization configuration

---

37. Security Best Practices

Never expose client secrets

Don't put:

client_secret

inside:

JavaScript
Mobile application
Git repository
Public configuration

---

Always use HTTPS

Tokens and credentials should never be sent over plain HTTP in production.

---

Use short-lived access tokens

Shorter token lifetimes reduce the impact of token leakage.

---

Use refresh tokens where appropriate

Authorization Code scenarios can use refresh tokens to obtain new access tokens without requiring the user to authenticate again.

---

Use PKCE

For public clients, PKCE provides additional protection for the Authorization Code flow.

---

Don't log access tokens

Avoid:

LOG.info("Token = " + token);

Tokens are sensitive credentials.

---

38. OAuth Flow Comparison

Flow	Typical Use
Client Credentials	Server-to-server
Authorization Code	User-facing applications
Authorization Code + PKCE	Public/mobile/browser clients
Password	Legacy/older implementations
Implicit	Legacy/deprecated

For modern SAP Commerce Cloud, focus your learning on:

Client Credentials
Authorization Code
PKCE
JWT

---

39. Real-World Example

Imagine an SAP Commerce architecture:

                 React Storefront
                       |
                       ↓
               Authorization Server
                       |
                       ↓
                  Access Token
                       |
                       ↓
                OCC Web Services
                       |
          ┌────────────┴────────────┐
          ↓                         ↓
       Product                    Cart
          ↓                         ↓
       Facade                    Facade
          ↓                         ↓
       Service                   Service

The React application doesn't directly access:

ProductModel
CartModel
OrderModel

It communicates with OCC using REST APIs and OAuth-based security.

---

40. Interview Question: What is OAuth2 in SAP Commerce?

A good answer:

OAuth 2.0 is the authorization framework used to secure SAP Commerce OCC Web Services. A client obtains an access token from the authorization server and sends that token in the Authorization Bearer header when calling protected OCC resources. Spring Security validates the request and authorization is based on the authenticated principal and configured roles.

---

41. Interview Question: Authentication vs Authorization?

Answer:

Authentication verifies the identity of the client or user. Authorization determines whether that authenticated principal has permission to access a particular resource or perform an operation.

---

42. Interview Question: What is a JWT?

Answer:

JWT stands for JSON Web Token. It is a signed, self-contained token containing claims. In current SAP Commerce Cloud JDK 21 OAuth support, JWTs are used as access tokens. The OCC resource server validates the token signature using public keys exposed through the JWKS mechanism.

---

43. Interview Question: What is Client Credentials Flow?

Answer:

Client Credentials is used for machine-to-machine communication where there is no end-user involved. The client authenticates using its configured credentials and receives an access token that it can use to access authorized resources.

---

44. Interview Question: What is Authorization Code Flow?

Answer:

Authorization Code is used when a user is involved. The client redirects the user to the authorization server, the user authenticates and grants access, and the client receives an authorization code which is exchanged for an access token.

---

45. Interview Question: What is PKCE?

Answer:

PKCE stands for Proof Key for Code Exchange. It adds a code verifier/challenge mechanism to the Authorization Code flow and helps protect public clients from authorization-code interception attacks.

---

46. Interview Question: 401 vs 403?

Answer:

401 → Authentication problem

403 → Authorization problem

For example:

401
No/invalid/expired token

403
Valid identity but insufficient permissions

---

47. Interview Question: Can OCC APIs be anonymous?

Answer:

Yes. Some OCC endpoints can be accessed anonymously depending on their security configuration. However, protected APIs require appropriate authentication and authorization. Anonymous access does not mean that all security checks are bypassed.

SAP explicitly documents public OCC endpoints and notes that some operations may still require an appropriate client token even when the endpoint does not require a customer login.

---

48. Interview Scenario

Question

Your OCC API works in Postman without authentication, but fails with:

401 Unauthorized

when called from the storefront.

What would you check?

Answer

I would investigate:

1. Is the storefront sending the Authorization header?

2. Is the access token expired?

3. Is the token issued for the correct client?

4. Is the endpoint protected?

5. Are the storefront and OCC using the same OAuth configuration?

6. Is Spring Security configured correctly?

7. Are there environment-specific properties?

8. Is HTTPS/proxy configuration affecting the request?

---

49. Another Interview Scenario

Question

The token is valid, but your API returns:

403 Forbidden

What do you check?

Answer

I would check:

User/client roles
       ↓
Endpoint authorization
       ↓
Spring Security configuration
       ↓
Required OCC role
       ↓
Base site/security configuration

The key point is that authentication succeeded but authorization failed.

---

50. Complete OCC Security Flow

Remember this diagram:

                    CLIENT
                       |
                       |
               Request Token
                       |
                       ↓
              AUTHORIZATION
                 SERVER
                       |
                       |
                  JWT TOKEN
                       |
                       ↓
                    CLIENT
                       |
                       |
          Authorization: Bearer JWT
                       |
                       ↓
                OCC WEB LAYER
                       |
                       ↓
              SPRING SECURITY
                       |
             ┌─────────┴─────────┐
             ↓                   ↓
        Authentication      Authorization
             |                   |
             └─────────┬─────────┘
                       ↓
                OCC CONTROLLER
                       |
                       ↓
                    FACADE
                       |
                       ↓
                   SERVICE
                       |
                       ↓
                     DAO
                       |
                       ↓
                  DATABASE

---

Conclusion

OAuth 2.0 is a fundamental part of SAP Commerce OCC security.

The most important concepts to remember are:

OAuth 2.0
    ↓
Authorization Server
    ↓
Access Token
    ↓
Bearer Token
    ↓
Spring Security
    ↓
Authentication
    ↓
Authorization
    ↓
OCC API

For modern SAP Commerce Cloud, especially JDK 21 environments, pay particular attention to:

JWT
Client Credentials
Authorization Code
PKCE
Spring Security
Resource Server
Authorization Server

Also remember that OAuth configuration differs between older and newer Commerce releases. Don't copy OAuth configuration from an old SAP Commerce project without checking the target Commerce/JDK version first.