OCAPI Session Bridge

To allow seamless interaction between OCAPI and your session-based storefront we offer the OCAPI session bridge. It allows you to obtain a JWT for a session and vice versa without having to reauthenticate the customer.

Technically the bridge consists of two resources:

  1. Request a JWT for a session via /customers/auth resource.

  2. Request a session for a JWT via /sessions resource.

To obtain a JWT for a guest or registered customer you have to pass a valid dwsid cookie to /customers/auth resource. You have to use "type":"session". If you haven't enabled the global security preference Enforce HTTPS, you must also pass a valid dwsecuretoken in the request. If successful, you get the JWT back as Authorization:Bearer response header.

The following sample shows how this approach works when the global security preference Enforce HTTPS isn't enabled and the dwsecuretoken is included in the request.

When the global security preference Enforce HTTPS is enabled, the request would be similar to this example, which doesn't include a dwsecuretoken:

Note: There’s no tight coupling between session and JWT. You get different tokens for multiple requests with the same session. Therefore, you should make only one call per session.

For more details see /customers/auth resource.

To obtain a session for a guest or registered customer you have to pass a valid JWT to /sessions resource. The JWT has to be passed as Authorization:Bearer request header. If successful, you get the session cookies back.

If you haven't enabled the global security preference Enforce HTTPS, the response includes a Set-Cookie header for a dwsecuretoken. The Set-Cookie header for a dwsecuretoken isn't included in the response if the global security preference Enforce HTTPS is enabled.

The following sample shows how this approach works when the global security preference Enforce HTTPS isn't enabled and the dwsecuretoken is included as a Set-Cookie header in the response.

When the global security preference Enforce HTTPS is enabled, the response would be similar to this example, which doesn't include a Set-Cookie header for a dwsecuretoken.

Note: There’s no tight coupling between session and JWT. You get different sessions for multiple requests with the same JWT. Means, you should make only one call per JWT.

For more details see /sessions resource.