MYSAPSSO2 Token Tool v2 — enhanced

Decode and encode SAP SSO2 logon tickets — v2: corrected field semantics and SAP-verified signing, based on a real S/4HANA deployment

Base64 Token

Ctrl+Enter to submit

Decoded Fields

Field	Value	Hex

What's new in v2 — corrections from a real S/4HANA deployment (kernel 7.93, CommonCryptoLib 8.5.x): field 4 is the creation time (not expiry), System ID/Client identify the issuer (not the target), signing now uses the SAP-accepted recipe (SHA-1 digest, detached, no authenticatedAttributes), and the decoder warns about conditions that make SAP reject a ticket. See the "Getting SAP to Accept Your Token" section below.

What is MYSAPSSO2?

MYSAPSSO2 is an SAP SSO2 logon ticket — a cookie-based Single Sign-On token used by SAP systems. When a user authenticates to an SAP system, the server issues a signed ticket stored as the MYSAPSSO2 browser cookie. Other SAP systems that trust the issuer's certificate can accept the ticket for passwordless login.

Token Structure

The token is a base64-encoded binary blob with this layout:

Offset	Content
0	Version byte (usually `0x02`)
1–4	Codepage — 4 ASCII bytes (e.g. `4103`)
5…n	TLV (Tag-Length-Value) fields — see table below
n+1	`0xFF` end-of-fields marker
n+2…n+3	Signature length — 2-byte big-endian uint16
n+4…	PKCS#7 / CMS signature block (BER/DER encoded)

Common TLV fields:

ID	Name	Encoding
0x01	User	UTF-16LE text
0x02	System ID — issuer, not target	UTF-16LE text
0x03	Client — issuer, not target	UTF-16LE text
0x04	Creation time (not expiry — SAP adds its own validity period)	UTF-16LE `YYYYMMDDHHmmss` UTC
0x05	Signature Flags	Raw bytes (hex)
0x06	Recipient Info	UTF-16LE text
0x09	Short Info	UTF-16LE text

How to Use — Decode

Get the token from your browser cookies (look for MYSAPSSO2) or from an HTTP Authorization header.
Paste the base64 string into the Decode tab and click Decode Token.
Or click Load Example to generate a sample token and decode it instantly.
The decoded fields table shows each TLV field's label, value, and raw hex bytes.
If the token has a PKCS#7 signature, the issuer CN, serial number, digest algorithm, and signing time are shown below the fields. SAP typically uses BER indefinite-length encoding for the signature block.

How to Use — Encode

User (required) — the SAP username to embed in the ticket.
System ID — 3-character identifier of the issuing system (your application). The target SAP system never appears in the token; the issuer values must match the ACL entry in the target's STRUSTSSO2.
Client — 3-digit client of the issuing system.
Creation Time — when the token is created (defaults to now), auto-formatted to YYYYMMDDHHmmss UTC. This is not an expiry — SAP computes expiration as creation time + login/ticket_expiration_time (default 8h) and rejects tokens with a future creation date.
Signing — optionally provide a PEM private key and certificate to produce a PKCS#7-signed token. The certificate must be SHA-1-signed for SAP to verify it.
Without signing, the token is structurally valid but unsigned — useful for testing and development.
After encoding, click Decode This to verify the token round-trips correctly.

Getting SAP to Accept Your Token

Hard-won requirements from a real S/4HANA deployment (kernel 7.93, CommonCryptoLib 8.5.x). All of these fail silently at import time and only show up in kernel traces:

SHA-1-signed certificate — generate with openssl req -sha1 …. A sha256WithRSAEncryption certificate imports into STRUSTSSO2 fine but verification fails with SsfVerify returned 5.
No authenticatedAttributes in the PKCS#7 signature — with RSA keys, CommonCryptoLib cannot verify signatures computed over authenticated attributes (SSF_API_SIGNER_ERRORS). This tool signs without them.
SHA-1 digest — SAP expects Alg=SHA1; SHA-256 digests are rejected. DSA 1024 + SHA-1 works on all NetWeaver versions; RSA 2048 + SHA-1 works on CommonCryptoLib 8.x.
Creation time, not expiry, in field 4 — a future timestamp triggers invalid format: ticket creation date / HMskiCheckValidity failed.
RZ11: login/accept_sso2_ticket = 1 on the accepting system.
STRUSTSSO2 is client-dependent — import the certificate into the Certificate List in client 000, but add the ACL entry (issuer System ID + Client from the token) in the client users log into. The ACL table is TWPSSO2ACL (check via SM30). Missing entry: No entry in TWPSSO2ACL for SYS … and CLI ….
ICM soft restart after STRUSTSSO2 changes — SMICM → Administration → ICM → Exit Soft → Local (SAP Note 510007).
HTTP port in BTP destinations — point the destination at the backend's HTTP port (e.g. 8000), not the HTTPS port. If the sap-ssolist response header lacks r= entries, SSO ticket auth isn't active on that endpoint.

Limitations & Security Notes

Unsigned tokens will not be accepted by production SAP systems — they require a valid PKCS#7 signature from a trusted certificate.
When signing, the private key is sent to the server for processing. Only use this tool in trusted environments (localhost, internal network).
This tool is intended for development, testing, and educational purposes.
Never use real production private keys on untrusted servers.