Message decode
Decode SAML and WS-Federation message (requests and responses)
SAML / WS-Federation Debug message by decoding and verify its contents.
Paste in raw requests and responses and get them decoded automatically.
You can also paste in 'in context' messages meaning that you can paste in a full Fiddler request/response and the message will be identified and decoded.
Typical flow (SAML message type / WS-Federation message type):
STS: Security Token Server is the service that authenticates the user (for example by username/password) and issues a token with claims about the user
SP: Service Provider, is the same as RP
IdP: IDentity Provider, same as STS
If your text contains multiple messages, only the first will be decoded, and if your text contains both GET and POST messages, only the POST message will be decoded. So be aware of what you paste in.
All POST and GET requests/responses are decoded, that is AuthnRequest, Response, LogoutRequest, LogoutResponse, wsignin1.0, wsignout1.0 and wsignoutcleanup1.0.
Specifications of SAML 2.0 can be read here: SAML 2.0
Specifications of WS-Federation 1.2 can be read here: WS-Federation 1.2
Paste in raw requests and responses and get them decoded automatically.
You can also paste in 'in context' messages meaning that you can paste in a full Fiddler request/response and the message will be identified and decoded.
Typical flow (SAML message type / WS-Federation message type):
- Unauthenticated user tries to browse RP and gets a (HTTP 302 Found) redirect to the STS to get authenticated (AuthnRequest / wsignin1.0)
- Browser performs a GET request to STS to get authenticated (AuthnRequest / wsignin1.0)
- User performs authentication at STS (for example by username/password) and on successfull authentication, the STS sends back a hidden form with token which automatically POST back to RP (Response / wsignin1.0)
- RP verifies the received token from the form POST and issues a session cookie if the verification was successfull and the user can use the application (Response / wsignin1.0)
- User signs out by the browser performs a GET request to STS to get signed out (LogoutRequest / wsignout1.0)
- All upstream STS's get a signout request and respond back and finally the RP receives a request telling it to delete cached session state for the specified user (LogoutResponse / wsignoutcleanup1.0)
STS: Security Token Server is the service that authenticates the user (for example by username/password) and issues a token with claims about the user
SP: Service Provider, is the same as RP
IdP: IDentity Provider, same as STS
If your text contains multiple messages, only the first will be decoded, and if your text contains both GET and POST messages, only the POST message will be decoded. So be aware of what you paste in.
All POST and GET requests/responses are decoded, that is AuthnRequest, Response, LogoutRequest, LogoutResponse, wsignin1.0, wsignout1.0 and wsignoutcleanup1.0.
Specifications of SAML 2.0 can be read here: SAML 2.0
Specifications of WS-Federation 1.2 can be read here: WS-Federation 1.2