SAML デコーダー

Base64 エンコードされた SAML Response と Assertion XML に対応しており、SAML リダイレクトや POST バインディングで一般的に見られる形式です。Deflate 圧縮された SAML リクエストも自動検出して展開します。

はい。すべての処理はブラウザ内で行われます。SAML トークンがサーバーに送信されることはありません。データがデバイスの外に出ることはありません。

HTTP リダイレクト経由で送信される SAML リクエストは、URL の長さを短縮するため Base64 エンコードの前に Deflate 圧縮されることがよくあります。このツールはそのようなデータを自動的に検出して展開します。

リクエストは、サービスプロバイダー（SP）がアイデンティティプロバイダー（IdP）に対してユーザーの認証を要求するために送信する samlp:AuthnRequest です。レスポンスはその返答として返ってくる samlp:Response で、認証ステートメントと属性を含む saml:Assertion を運びます。どちらも、URL エンコードされた形（Redirect バインディング）で、または HTML フォーム POST の中（POST バインディング）で送受信されます。このツールはどちらの方向でもデコードできます。

SP がリクエストに添付し、IdP がレスポンスとともにそのまま返さなければならない不透明な文字列で、通常はログイン後のリダイレクト先の URL です。SAML バインディング仕様では 80 バイト未満に保つことが推奨されており、IdP にとっては何の意味も持ちません。SSO が誤ったページに着地した場合は、失われたか壊れた RelayState が第一の容疑者です。

HTTP-Redirect バインディングでは、XML は raw Deflate で圧縮され、次に Base64、その後 URL エンコードされます。これが仕様で定められた 3 つのステップです。URL エンコードされた値をこのツールに入力してみてください。< で始まるマークアップに展開されれば圧縮されていたことになり、すでに <?xml や <saml で始まっていれば圧縮されていません。POST バインディングのメッセージは、Deflate を使わない Base64 です。

クロックスキュー：SP と IdP の時計のずれが許容されるドリフトを超えると、署名検証が失敗します。オーディエンスの不一致：アサーション内の audienceRestriction に SP の entity ID が含まれていません。さらに、期限切れのレスポンス（NotOnOrAfter）も原因になります。よくある原因としてはこのほか、RelayState の欠落や、SP が署名を必須としている場合の未署名アサーションが挙げられます。このツールが表示するデコード済みのフィールドで、これらの点を一つずつ直接確認できます。

はい、できます。デコードは検証ではないためです。アサーションの XML は誰でも読み取れます。内部の署名が担保するのは完全性であって、機密性ではありません。IdP の公開証明書なしにはできないのは、アサーションが本物で改変されていないことを証明することです。デコードされた内容は慎重に扱ってください。アサーションには、メールアドレス、グループ、権限（entitlement）などの情報が含まれていることがよくあります。