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 │
│ │
└─────────────────────────────────────────────────────────────────┘
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 Attribute | OIDC Claim | Description |
|---|---|---|
NameID | sub | Unique user identifier |
urn:oid:0.9.2342.19200300.100.1.3 | email | User email address |
urn:oid:2.5.4.42 | given_name | First name |
urn:oid:2.5.4.4 | family_name | Last name |
urn:oid:2.5.4.3 | name | Full display name |
memberOf | groups | Group memberships |
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:
./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:
./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
Shyntr validates all cryptographic signatures on SAML assertions and OIDC tokens. Never disable signature validation in production.
| Protocol | Validation |
|---|---|
| SAML Response | XML signature verification against IdP certificate |
| SAML Assertion | Assertion signature (if signed separately) |
| OIDC ID Token | JWT signature verification using IdP JWKS |
| OIDC Access Token | Optional signature verification |
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
// 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
}
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)
Shyntr prioritizes protocol compliance over convenience. This ensures interoperability with any standards-compliant service.
Next Steps
- Learn about Multi-Tenancy for serving multiple organizations
- Understand Zero Trust Security features
- Follow the guide to Manage Clients & Identity Providers