Skip to main content
Version: 1.1

Protocol Translation

One of Shyntr's core capabilities is its ability to act as a protocol translator between SAML 2.0 and OpenID Connect/OAuth2. This enables organizations to maintain their existing identity infrastructure while adopting new applications without protocol constraints.

The Problem​

Enterprise environments often face a fragmented authentication landscape:

┌─────────────────────────────────────────────────────────────────┐
│                    Typical Enterprise Reality                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│      Legacy Applications          Modern Applications           │
│      ┌──────────────────┐        ┌──────────────────┐           │
│      │  ERP System      │        │  React SPA       │           │
│      │  (SAML Only)     │        │  (OIDC Only)     │           │
│      └──────────────────┘        └──────────────────┘           │
│                                                                 │
│      ┌──────────────────┐        ┌──────────────────┐           │
│      │  Corporate ADFS  │        │  Mobile App      │           │
│      │  (SAML IdP)      │        │  (OAuth2)        │           │
│      └──────────────────┘        └──────────────────┘           │
│                                                                 │
│       ❌ Incompatible protocols = Integration nightmare         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

The Solution​

Shyntr acts as a universal adapter, translating protocol flows bidirectionally:

┌─────────────────────────────────────────────────────────────────┐
│                          With Shyntr                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  SAML Clients          ┌──────────────┐        OIDC Providers   │
│  ┌─────────────┐       │              │       ┌─────────────┐   │
│  │ ERP System  │──────▶│   Shyntr     │◀──────│ Auth0       │   │
│  └─────────────┘       │              │       └─────────────┘   │
│                        │  Protocol    │                         │
│  OIDC Clients          │  Translation │        SAML Providers   │
│  ┌─────────────┐       │   Engine     │       ┌─────────────┐   │
│  │ React SPA   │──────▶│              │◀──────│ Okta SAML   │   │
│  └─────────────┘       └──────────────┘       └─────────────┘   │
│                                                                 │
│      ✅ Unified authentication through protocol bridging        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Identity Broker & Protocol Translation Flow​

Shyntr acts as a universal translator between modern (OIDC/OAuth2) and legacy (SAML 2.0) authentication protocols. The following sequence diagram illustrates a complex scenario where a legacy SAML application authenticates a user via a modern OIDC Identity Provider (e.g., Google or Azure AD) using Shyntr as the broker.

This architecture ensures that your legacy applications can benefit from modern authentication methods without any code changes on the Service Provider side.

Supported Flows​

SAML to OIDC Translation​

When a SAML Service Provider initiates authentication, Shyntr can validate the user against an OIDC Identity Provider:

Use Case: Your enterprise customer uses Salesforce (SAML SP), but your company standardized on Google Workspace (OIDC IdP).

OIDC to SAML Translation​

When an OIDC/OAuth2 client needs to authenticate against a SAML Identity Provider:

Use Case: Your modern React application needs to support enterprise customers who only have corporate ADFS or Okta SAML.

Claim Mapping​

Shyntr automatically maps claims between protocols:

SAML AttributeOIDC ClaimDescription
NameIDsubUnique user identifier
urn:oid:0.9.2342.19200300.100.1.3emailUser email address
urn:oid:2.5.4.42given_nameFirst name
urn:oid:2.5.4.4family_nameLast name
urn:oid:2.5.4.3nameFull display name
memberOfgroupsGroup memberships
Custom Claim Mapping

You can configure custom claim mappings per tenant or per connection to match your specific attribute requirements.

Registering a SAML Connection​

To enable SAML IdP translation, register the external Identity Provider:

Register External SAML IdP
./shyntr create-saml-connection \
  --name "Corporate ADFS" \
  --metadata-file /path/to/idp-metadata.xml \
  --tenant-id default

The metadata file contains the IdP's:

  • Entity ID
  • SSO endpoints
  • Signing certificates
  • Name ID formats

Registering an OIDC Connection​

For OIDC IdP translation:

Register External OIDC IdP
./shyntr create-oidc-connection \
  --name "Google Workspace" \
  --issuer "https://accounts.google.com" \
  --client-id "your-google-client-id" \
  --client-secret "your-google-client-secret" \
  --tenant-id default

Shyntr will automatically discover endpoints via the .well-known/openid-configuration document.

Security Considerations​

Signature Validation​

Critical Security

Shyntr validates all cryptographic signatures on SAML assertions and OIDC tokens. Never disable signature validation in production.

ProtocolValidation
SAML ResponseXML signature verification against IdP certificate
SAML AssertionAssertion signature (if signed separately)
OIDC ID TokenJWT signature verification using IdP JWKS
OIDC Access Token (JWT)Cryptographic signature & claim verification required (Zero Trust)

Replay Protection​

Shyntr implements strict replay protection:

  • SAML: Message ID (InResponseTo) tracking
  • OIDC: JTI (JWT ID) claim tracking
  • Both: Timestamp validation with configurable clock skew tolerance
Internal Replay Check
// SAML Message ID is tracked to prevent assertion replay
if isMessageIDUsed(assertion.InResponseTo) {
    return ErrReplayDetected
}

// JTI tracking for JWT replay prevention
if isJTIUsed(idToken.Claims.JTI) {
    return ErrReplayDetected
}

Single Logout (SLO) Architecture​

Shyntr implements a highly robust, 3-phase Single Logout Service (SLS) for SAML to ensure completely synchronized session termination across all connected applications.

┌─────────────────────────────────────────────────────────────┐
│                 Shyntr 3-Phase SLO Routing                  │
├─────────────────────────────────────────────────────────────┤
│ 1. IdP-Initiated: Keycloak/ADFS says "User logged out here, │
│    kill your local sessions." Shyntr terminates the session │
│    and generates a LogoutResponse XML on the fly.           │
│                                                             │
│ 2. SP-Initiated (Initiate): User clicks Logout in Shyntr.   │
│    Shyntr generates a signed LogoutRequest and redirects    │
│    the user to the external Identity Provider.              │
│                                                             │
│ 3. SP-Initiated (Callback): External IdP returns a success  │
│    LogoutResponse. Shyntr finalizes local cleanup and       │
│    redirects the user to the safe post-logout URI.          │
└─────────────────────────────────────────────────────────────┘
Seamless Protocol Bridging

If a user logs in via a SAML Identity Provider but consumes an OIDC downstream application, initiating a logout from the OIDC app will automatically trigger the SAML SLO flow upstream!

Protocol Compliance​

Shyntr adheres to strict protocol specifications:

SAML 2.0​

  • SAML 2.0 Core Specification
  • SAML 2.0 Bindings (HTTP-POST, HTTP-Redirect)
  • SAML 2.0 Profiles (Web Browser SSO)
  • SAML 2.0 Metadata

OpenID Connect / OAuth 2.0​

  • OpenID Connect Core 1.0
  • OAuth 2.0 Authorization Framework (RFC 6749)
  • OAuth 2.0 Bearer Token Usage (RFC 6750)
  • JSON Web Token (RFC 7519)
  • JSON Web Key (RFC 7517)
  • Private Key JWT (RFC 7523)
Standards First

Shyntr prioritizes protocol compliance over convenience. This ensures interoperability with any standards-compliant service.

Next Steps​