DEV Community: Peter Anderson

Debugging SAML SSO: How to Decode a SAMLResponse (and Why It's Sometimes Not XML)

Peter Anderson — Sat, 08 Aug 2026 21:23:00 +0000

You're debugging a broken SSO login. The identity provider (IdP) redirects back to your app, and somewhere in the request is a big blob called SAMLResponse. You grab it, Base64-decode it, and expect to see clean XML.

Sometimes you do. Sometimes you get binary garbage that starts with bytes like 0x78 0x9c and looks nothing like markup.

Both outcomes are correct. The difference is which SAML binding the IdP used, and once you know the two encoding chains, SAML debugging stops being guesswork.

The two bindings, and their two encodings

SAML sends its messages (SAMLResponse, SAMLRequest) using one of two HTTP bindings, and they encode the payload differently:

HTTP-POST binding — the message rides in a hidden form field that auto-submits via POST. The value is simply:

Base64(XML)

Decode the Base64 and you get the assertion XML directly. This is the common case for the response coming back from the IdP.

HTTP-Redirect binding — the message rides in a URL query string, so it has to be small and URL-safe. The value is:

URLEncode( Base64( DEFLATE( XML ) ) )

That's three layers. If you only Base64-decode it, you're staring at the raw output of a DEFLATE compressor — which is exactly the binary garbage people report. This binding is typically used for SAMLRequest (the AuthnRequest your app sends to the IdP) and for Single Logout.

Critically, the redirect binding uses raw DEFLATE (RFC 1951) with no zlib header and no checksum. That's the single most common thing people get wrong — they reach for a normal zlib/gzip inflate, it chokes on the missing header, and they conclude the blob is corrupt. It isn't; it just needs a raw inflate.

Decoding both in Python

import base64
import zlib
from urllib.parse import unquote

# --- HTTP-POST binding: Base64(XML) ---
def decode_post(saml_response: str) -> str:
    return base64.b64decode(saml_response).decode("utf-8")

# --- HTTP-Redirect binding: URLEncode(Base64(DEFLATE(XML))) ---
def decode_redirect(saml_param: str) -> str:
    url_decoded = unquote(saml_param)          # 1. undo URL-encoding
    raw = base64.b64decode(url_decoded)        # 2. undo Base64
    # 3. RAW inflate: wbits = -15 => no zlib header, no checksum
    return zlib.decompress(raw, -15).decode("utf-8")

The magic number is that -15 passed as wbits. The negative sign tells zlib "this is raw DEFLATE, don't expect a header." Use zlib.decompress(data, -15) for the redirect binding, plain base64.b64decode for POST.

Not sure which binding you're holding? A quick heuristic: if Base64-decoding gives you text starting with <?xml or <saml, it's POST. If it gives you bytes, try a raw inflate — it's almost certainly Redirect.

What to actually read in the decoded assertion

Once you have XML, don't just admire it — the debugging clues are in specific fields:

Issuer — is this really from the IdP you configured? A mismatch means metadata drift.
Destination — must match your Assertion Consumer Service (ACS) URL. A trailing slash or http vs https mismatch here breaks validation.
<samlp:Status> StatusCode — Success vs something like Responder or AuthnFailed. This is the IdP telling you why it said no.
NameID + its Format — is the user identifier what your app expects (email vs persistent vs transient)? A format mismatch is a classic "logged in but no account found" bug.
Conditions NotBefore / NotOnOrAfter — these are usually a tight window (a few minutes). If the server clocks between IdP and SP drift, validation fails with a confusing "assertion expired" even though the login just happened. Clock skew is one of the most common SAML failures, and you can only see it by reading these timestamps.
AudienceRestriction Audience — must equal your SP entity ID. If it doesn't, the IdP issued the assertion for a different application.
Signature — check whether a <ds:Signature> is present. But note the trap: a signature being present is not the same as it being verified. Presence tells you the IdP signed something; only your SP validating it against the right certificate tells you it's trustworthy.

The Base64 errors you'll actually hit

If your IdP is Azure AD / Entra, you'll eventually meet AADSTS750056: SAMLResponse must be a properly formed and encoded ... Base64. Despite the wording, the assertion is usually fine — something mangled the transport:

A proxy or WAF stripping + characters (turning them into spaces), because + is significant in Base64 but also means "space" in some URL contexts. Result: an invalid Base64 string.
76-character line wrapping (MIME-style Base64) that a strict decoder rejects. Standard SAML Base64 should be one continuous string.

Both come down to the same fix: preserve the exact bytes end-to-end and don't let middleware "helpfully" rewrite the payload.

A security warning worth repeating

A SAML assertion is a credential. For its short validity window, whoever holds it can often impersonate the user. So when you decode one for debugging, decode it in something that runs client-side — never paste a production assertion into a random server-side online decoder, because you've just handed a live credential to a third-party server.

For quick local decoding there's a free browser-based tool that auto-detects the binding — it'll URL-decode, Base64-decode, and auto-inflate raw DEFLATE, pretty-print the XML, and pull out the claims for you, all 100% client-side with nothing sent to a server: SAML Decoder.

POST vs Redirect at a glance

	HTTP-POST binding	HTTP-Redirect binding
Encoding chain	`Base64(XML)`	`URLEncode(Base64(DEFLATE(XML)))`
Decode steps	Base64-decode	URL-decode → Base64-decode → raw inflate (`wbits=-15`)
Compression	None	Raw DEFLATE (no zlib header)
Typically used for	`SAMLResponse` from IdP	`SAMLRequest`, Single Logout
Base64-decode alone gives	Clean XML	Binary garbage (DEFLATE bytes)

TL;DR

A SAMLResponse that decodes to clean XML is the POST binding (Base64(XML)). One that decodes to binary is the Redirect binding (Base64(DEFLATE(XML)), URL-encoded).
For the redirect binding you must URL-decode, Base64-decode, then RAW-inflate — zlib.decompress(data, -15). Regular zlib/gzip inflate will fail on the missing header.
When reading the assertion, check Status, Destination, Audience, and especially the Conditions timestamps — clock skew is a top cause of "it authenticated but still failed."
Treat assertions as live credentials: decode them client-side, never on someone else's server.
AADSTS750056 usually means a proxy mangled + or line-wrapped the Base64, not a malformed assertion.

What's the weirdest SAML failure you've had to decode your way out of? Share it in the comments.

Decoding a PowerShell -EncodedCommand During Incident Response (the UTF-16 gotcha)

Peter Anderson — Sat, 08 Aug 2026 21:22:00 +0000

You're triaging an alert. Scheduled task, weird parent process, and a command line that looks like this:

powershell.exe -nop -w hidden -enc JABjACAAPQAg...

You know the drill: grab the Base64 blob, decode it, read the script. So you paste it into a decoder and get back this:

$ c   =   " h t t p : / / ...

Garbage. A space (or a null) between every single character. First instinct is that the payload is doubly-encoded or encrypted. It isn't. This is the single most common gotcha with -EncodedCommand, and once you know it, it takes ten seconds to fix.

Why it looks garbled

powershell.exe -enc (short for -EncodedCommand) expects Base64 of UTF-16LE (little-endian Unicode) bytes — not UTF-8. That's mandated by PowerShell itself, not a choice the attacker made.

In UTF-16LE, every ASCII character is stored as two bytes: the character followed by a 0x00 null byte. So the letter c isn't 0x63, it's 0x63 0x00. When you Base64-decode the blob and then read it as UTF-8, every one of those null bytes renders as a space or an invisible control character. Hence the h t t p spacing.

Text:      c        =        "
UTF-16LE:  63 00    3D 00    22 00
UTF-8 view: c  ␀     =  ␀     "  ␀     <- the null shows up as a "space"

Decode it as UTF-16LE instead and the nulls disappear, because that's what they were: the high byte of each 16-bit code unit.

Decode it correctly

In PowerShell itself — the encoding is literally called Unicode in .NET, which means UTF-16LE:

$enc = 'JABjACAAPQAg...'
[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($enc))

In Python — decode the bytes, then read them as utf-16-le:

import base64
enc = "JABjACAAPQAg..."
print(base64.b64decode(enc).decode("utf-16-le"))

In CyberChef — build the recipe From Base64 → Decode text (UTF-16LE). Or From Base64 then Remove null bytes for a quick-and-dirty look.

Any of these turns the spaced-out mess back into readable PowerShell.

The encode direction (for building test cases)

If you're writing detections or a lab sample, this is how the blob is produced — same Unicode/UTF-16LE contract in reverse:

$cmd = 'Write-Host "hello from encoded command"'
[System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($cmd))

Feed that output back to powershell -enc and it runs. Legit automation uses this all the time — it's a clean way to pass a multi-line script through a single argument without quoting nightmares. That's exactly why malware hides in the same crowd.

The second layer: it's often gzip too

Sometimes you decode correctly and still get binary garbage. That's the next common trick: the real script is gzip-compressed, then Base64'd. The outer PowerShell you just decoded is a tiny loader whose whole job is to inflate the inner payload in memory:

# telltale pattern inside the decoded stub
$s = New-Object IO.MemoryStream(,[Convert]::FromBase64String("H4sIA..."))
IO.StreamReader(New-Object IO.Compression.GzipStream($s,[IO.Compression.CompressionMode]::Decompress)).ReadToEnd()

The tell is the inner Base64 starting with H4sI — that's the gzip magic number (1f 8b) in Base64. When you see it, decode Base64 again and gunzip to reach the actual script. Payloads can nest two or three layers deep this way.

Is it safe to decode a suspicious sample?

Yes. Decoding is not executing. Converting Base64 back to text and inflating gzip are pure data transformations — no powershell.exe runs, nothing touches the script block, nothing hits the network. The danger is only if you run the decoded command. So decode freely and read; just don't pipe the result into a shell.

For fast triage there's a free browser-based tool that decodes -enc / -EncodedCommand for you — it handles the UTF-16LE conversion and auto-inflates nested gzip layers, and it runs entirely client-side so it's safe to paste suspicious samples into (nothing is uploaded): PowerShell Encoded Command Decoder.

Analyst checklist vs. the layers

What you see after decoding	What it means	Next step
Space between every char	You decoded as UTF-8	Re-decode as UTF-16LE
Clean, readable PowerShell	Done	Read it, extract IOCs
Binary garbage, starts `H4sI`	Inner gzip payload	Base64-decode again, then gunzip
Another `-enc` / `FromBase64String`	Nested loader	Repeat the whole process on the inner blob

TL;DR

powershell -enc <base64> is Base64 of UTF-16LE, not UTF-8 — that's why naive decoding shows a space/null between every character.
Decode it right with [System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($enc)), or in Python with base64.b64decode(enc).decode("utf-16-le").
If the result is still binary and starts with H4sI, it's gzip inside Base64 — inflate it to reach the real script.
Decoding never executes the command, so it's safe to analyze suspicious samples locally.

Seen a -enc payload with an interesting nesting trick? Share the pattern in the comments.

Sending Images to GPT-4o, Claude, and Gemini: The Base64 Payload Each One Wants

Peter Anderson — Sat, 08 Aug 2026 21:09:29 +0000

You want to send a screenshot to a vision model. All three of the big ones — OpenAI's GPT-4o, Anthropic's Claude, Google's Gemini — accept images the same fundamental way: Base64-encode the bytes and put them in the JSON request. No file uploads, no multipart, just text in a payload.

And yet the single most common error people hit is some flavor of invalid image / could not process image. The reason is almost never the image. It's that each provider wants the Base64 wrapped in a differently shaped object, and the traps are subtle — especially the data: URL prefix, which one provider requires and the other two reject.

Here's the exact payload each one wants, side by side.

OpenAI (GPT-4o)

GPT-4o uses a content array of parts. The image is an image_url part, and — this is the trap — the url field takes a full data URL, prefix and all:

import base64
from openai import OpenAI

client = OpenAI()

with open("photo.png", "rb") as f:
    b64 = base64.standard_b64encode(f.read()).decode("utf-8")

resp = client.chat.completions.create(
    model="gpt-4o",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "What's in this image?"},
            {
                "type": "image_url",
                "image_url": {"url": f"data:image/png;base64,{b64}"},
            },
        ],
    }],
)
print(resp.choices[0].message.content)

The literal payload shape:

{ "type": "image_url", "image_url": { "url": "data:image/png;base64,<BASE64>" } }

Note the data:image/png;base64, is part of the value. Send raw Base64 here and it fails.

Anthropic (Claude)

Claude uses an image content block with a source object. Here the MIME type is a separate field (media_type), and the data field wants raw Base64 — no data: prefix:

import base64
import anthropic

client = anthropic.Anthropic()

with open("photo.png", "rb") as f:
    b64 = base64.standard_b64encode(f.read()).decode("utf-8")

msg = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{
        "role": "user",
        "content": [
            {
                "type": "image",
                "source": {
                    "type": "base64",
                    "media_type": "image/png",
                    "data": b64,   # raw, NO data: prefix
                },
            },
            {"type": "text", "text": "What's in this image?"},
        ],
    }],
)
print(msg.content[0].text)

The literal payload shape:

{ "type": "image", "source": { "type": "base64", "media_type": "image/png", "data": "<BASE64>" } }

If you paste a data:image/png;base64,... string into data here, Claude will reject it — the prefix is not valid Base64.

Google (Gemini)

Gemini uses parts with an inline_data object: a mime_type field plus raw Base64 (again, no prefix):

import base64
from google import genai
from google.genai import types

client = genai.Client()

with open("photo.png", "rb") as f:
    image_bytes = f.read()

resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=[
        types.Part.from_bytes(data=image_bytes, mime_type="image/png"),
        "What's in this image?",
    ],
)
print(resp.text)

The SDK handles the encoding for you above, but the wire payload it builds is:

{ "inline_data": { "mime_type": "image/png", "data": "<BASE64>" } }

One more Gemini gotcha: the JavaScript SDK camelCases these keys — it's inlineData and mimeType, not inline_data / mime_type. Same structure, different casing.

The three shapes at a glance

Provider	Field the image goes in	`data:` prefix?	Raw Base64?	MIME type lives in
OpenAI (GPT-4o)	`image_url.url`	Yes — full data URL	No	Inside the data URL
Anthropic (Claude)	`source.data`	No	Yes	`source.media_type`
Google (Gemini)	`inline_data.data`	No	Yes	`inline_data.mime_type`

Read it top to bottom: OpenAI is the odd one out that wants the whole data: URL; Claude and Gemini both want raw Base64 with the MIME type broken out into its own field.

Why you're getting "invalid image"

When a request fails, it's almost always one of these:

Stray data: prefix where raw Base64 is expected. Sending data:image/png;base64,iVBOR... to Claude or Gemini's data field. They want just iVBOR....
Missing data: prefix where OpenAI wants it. Sending raw Base64 to GPT-4o's image_url.url. It wants the full data URL.
Mismatched MIME type. Declaring image/jpeg for a PNG (or vice versa). The declared type must match the actual bytes. A telltale sign: your Base64 starts with iVBORw0KGgo (PNG) but you labeled it image/jpeg (JPEG bytes start /9j/).
Whitespace or newlines in the Base64. Some encoders (looking at you, base64 CLI without -w0, and older MIME encoders) wrap output at 76 columns. Strip newlines before sending.
Unsupported format. Stick to PNG, JPEG, WebP, and non-animated GIF. HEIC, SVG, TIFF, and animated GIFs are frequent rejects.
Too large. OpenAI and Claude cap around ~5 MB per image; Gemini allows up to ~20 MB of inline data per request, and above that you're expected to use its Files API instead of inline Base64. Remember Base64 inflates size by ~33%, so a 4 MB file is ~5.3 MB on the wire.

If you just need to grab a correct Base64 string and see the exact payload for each provider without wiring up a script, there's a free browser tool that encodes an image locally (nothing gets uploaded) and shows the ready-to-paste block for all three: Image to Base64 for AI Vision. There are also provider-specific walkthroughs for Claude and Gemini if you only care about one.

TL;DR

All three vision APIs take images as Base64 in the JSON body — no uploads needed.
GPT-4o wants a full data: URL in image_url.url.
Claude wants raw Base64 in source.data, with the type in source.media_type.
Gemini wants raw Base64 in inline_data.data, with the type in inline_data.mime_type (inlineData/mimeType in the JS SDK).
Most invalid image errors are a misplaced data: prefix, a mismatched MIME type, whitespace, or a file over the size cap (~5 MB OpenAI/Claude, ~20 MB Gemini inline).

Get the wrapper right and vision "just works" across all three.

Which provider's payload has bitten you the hardest? Share your worst invalid image story in the comments.

Kubernetes Secrets Are Just Base64 Not Encryption. Here's What That Actually Means

Peter Anderson — Sat, 08 Aug 2026 20:55:31 +0000

If you've run Kubernetes for more than a day, you've seen this:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=
  password: c3VwZXJzZWNyZXQ=

And somewhere in the back of your mind you filed it under "encrypted credentials." It isn't. Those values are Base64, and Base64 is encoding, not encryption. YWRtaW4= is just admin written in a different alphabet — reversible instantly, by anyone, with no key.

This trips up an astonishing number of teams, so let's clear it up for good.

Prove it in one command

kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 --decode
# supersecret

No key. No password. No "decryption." Base64 is a binary-to-text encoding — its entire job is to represent arbitrary bytes using a safe 64-character alphabet so they survive transport and storage in text-based systems (etcd, YAML, JSON, HTTP headers). Kubernetes encodes Secret data values purely so binary values (certs, keys, gzip blobs) can live inside a YAML/JSON object. That's it. Security was never the point.

If you want to eyeball a whole Secret at once instead of decoding fields one by one, I built a small in-browser tool for exactly this — paste the YAML and it decodes every data: value locally (nothing is uploaded): Kubernetes Secret Decoder. (Disclosure: it's my free, no-ads tool.)

`data` vs `stringData`

A quick related gotcha: data expects Base64, but stringData expects plain text and Kubernetes Base64-encodes it for you on write:

stringData:
  password: supersecret   # plain text; k8s encodes it into data.password

Both end up identically un-secret at rest.

So what actually protects a Secret?

Base64 gets you nothing here. Real protection is layered:

Encryption at rest for etcd — configure a KMS provider (AWS/GCP/Azure KMS) or at minimum aescbc/secretbox via an EncryptionConfiguration. Without this, Secrets sit in etcd Base64-only.
Sealed Secrets (Bitnami) — encrypt secrets before they hit Git; only the in-cluster controller can decrypt. Safe to commit.
SOPS (+ age/KMS) — encrypt values in your manifests/GitOps repo.
External secret stores — HashiCorp Vault, AWS Secrets Manager, etc., pulled in via the External Secrets Operator.
RBAC — lock down who can get/list Secrets. If a ServiceAccount can read the Secret, it can read the plaintext.

Encoding vs encryption vs hashing (the mental model)

	Encoding (Base64)	Encryption (AES-GCM)	Hashing (SHA-256)
Purpose	Safe transport of bytes	Confidentiality	Integrity / fingerprint
Needs a key?	No	Yes	No
Reversible?	Yes, trivially	Yes, with the key	No (one-way)
Hides data?	No	Yes	N/A

Base64 is in the left column. Kubernetes Secrets, out of the box, are in the left column. If you want to go deeper on that distinction, here is a helpful article: Is Base64 Encryption?

TL;DR

A Kubernetes Secret's data is Base64, not encrypted — decode it with one base64 -d.
Treat any Secret YAML as plaintext credentials: don't commit it, lock down RBAC.
For actual protection: encryption at rest (KMS), Sealed Secrets, SOPS, or an external secret store.

The next time someone says "it's fine, it's in a Secret," you'll know to ask the real question: is etcd encrypted, and who has RBAC to read it?

What's bitten you with Kubernetes Secrets? Drop it in the comments.

DEV Community: Peter Anderson

Debugging SAML SSO: How to Decode a SAMLResponse (and Why It's Sometimes Not XML)

The two bindings, and their two encodings

Decoding both in Python

What to actually read in the decoded assertion

The Base64 errors you'll actually hit

A security warning worth repeating

POST vs Redirect at a glance

TL;DR

Decoding a PowerShell -EncodedCommand During Incident Response (the UTF-16 gotcha)

Why it looks garbled

Decode it correctly

The encode direction (for building test cases)

The second layer: it's often gzip too

Is it safe to decode a suspicious sample?

Analyst checklist vs. the layers

TL;DR

Sending Images to GPT-4o, Claude, and Gemini: The Base64 Payload Each One Wants

OpenAI (GPT-4o)

Anthropic (Claude)

Google (Gemini)

The three shapes at a glance

Why you're getting "invalid image"

TL;DR

Kubernetes Secrets Are Just Base64 Not Encryption. Here's What That Actually Means

Prove it in one command

data vs stringData

So what actually protects a Secret?

Encoding vs encryption vs hashing (the mental model)

TL;DR

`data` vs `stringData`