Secured EDI integration with transportation carriers using JWT authentication reduced unauthorized access attempts by 90%

We successfully implemented JWT-based authentication for our EDI integration with 30+ transportation carriers in Infor SCM IS 2023.1. Previously, we used static credentials embedded in our EDI translator, which posed security risks and made credential rotation painful.

The challenge was replacing long-lived static credentials with short-lived JWT tokens while maintaining reliable EDI transaction processing. Our transportation management module processes 5,000+ shipment transactions daily across multiple carriers, requiring high availability and security. The solution involved implementing JWT token generation, automated key rotation, and short token lifetimes to minimize unauthorized access risk.

We implemented a token refresh mechanism within our EDI processor. Before each transaction batch, the processor checks token expiration and proactively refreshes if within 5 minutes of expiry. This prevents mid-batch failures. The key was separating token management from transaction processing logic.

Did you face any resistance from carriers during this transition? Some of our carriers are still using legacy EDI systems and might not support JWT authentication. How did you manage the migration without disrupting operations?

Let me provide a comprehensive overview of our JWT implementation, addressing all the key focus areas:

JWT Token Implementation: We built a centralized authentication service that generates JWT tokens for all carrier communications. The implementation uses RS256 algorithm (RSA signatures) rather than HS256 to avoid sharing secret keys with carriers:

String token = JWT.create()
  .withIssuer("infor-scm-transport")
  .withAudience(carrierCode)
  .withExpiresAt(Date.from(Instant.now().plusSeconds(900)))
  .sign(Algorithm.RSA256(privateKey));

Token lifetime is 15 minutes, balancing security with operational reliability. The short lifetime significantly reduces the window of vulnerability if a token is compromised. Each token includes carrier-specific claims (carrierCode, authorized transaction types, rate limits) to implement fine-grained access control.

Our EDI translator was modified to request tokens from the authentication service before each batch process. The service maintains a token cache - if a valid token exists for a carrier, it’s reused; otherwise, a new token is generated. This minimizes token generation overhead while maintaining security.

Key Rotation Policy: We implemented a 90-day key rotation schedule with a 7-day overlap period. Here’s how it works:

Day 0: Generate new RSA key pair (4096-bit)

Day 1-7: Both old and new public keys published in JWKS endpoint

Day 7: Start signing new tokens with new private key

Day 14: Remove old public key from JWKS endpoint

Day 90: Repeat process

The overlap period is critical - carriers can validate tokens signed with either key during the transition. Our JWKS endpoint publishes both keys with appropriate ‘kid’ (key ID) headers:

{
  "keys": [
    {"kid": "2023-Q2", "kty": "RSA", "use": "sig", "n": "..."},
    {"kid": "2023-Q3", "kty": "RSA", "use": "sig", "n": "..."}
  ]
}

Carriers fetch this endpoint periodically (we recommend hourly) to stay synchronized with current keys. During the 90-day period, we monitor which carriers are actively validating tokens and send reminder notifications before key rotation.

Short Token Lifetimes: The 15-minute token lifetime was chosen after analyzing our EDI processing patterns. Most EDI batches complete within 10 minutes, so 15 minutes provides adequate buffer. For the rare long-running processes, we implemented automatic token refresh:

  1. EDI processor checks token expiration before each transaction
  2. If remaining lifetime < 5 minutes, request new token
  3. Update HTTP Authorization header with new token
  4. Continue processing without interruption

This approach eliminated the mid-batch failures we initially experienced during testing. The short lifetime means that even if a token is intercepted (e.g., from network logs), it’s only valid for 15 minutes and only for the specific carrier it was issued to.

We also implemented token revocation for emergency scenarios. If a security incident is detected, we can revoke specific tokens by maintaining a deny-list in Redis with 15-minute TTL. The authentication service checks this deny-list before accepting any token.

Carrier Migration Strategy: We used a phased rollout over 6 months:

Phase 1 (Months 1-2): Implemented JWT for 5 pilot carriers with modern APIs

Phase 2 (Months 3-4): Migrated 15 carriers with REST-based EDI

Phase 3 (Months 5-6): Remaining carriers, including legacy systems

For carriers with legacy EDI systems that couldn’t support JWT, we deployed an authentication proxy. The proxy sits between Infor SCM and the carrier, handling JWT authentication on behalf of the legacy system. The proxy validates incoming JWTs and translates them to whatever authentication method the carrier supports (basic auth, API keys, etc.).

This hybrid approach allowed us to standardize on JWT internally while accommodating carrier technical limitations. The proxy also provides a migration path - as carriers modernize their systems, we can remove the proxy and enable direct JWT authentication.

Results: After full implementation, we’ve seen:

  • Zero security incidents related to credential compromise (previously 2-3 annually)
  • 87% reduction in time spent on credential rotation (automated vs. manual carrier coordination)
  • Improved audit compliance with detailed token issuance and validation logs
  • Better carrier relationship management through standardized authentication approach

The initial investment was significant (3 months development, 6 months rollout), but the security and operational benefits have been substantial. The key success factors were: proper token lifetime tuning, robust key rotation process, and phased carrier migration with proxy fallback for legacy systems.