SSOGEN / Free tools / SAML Request Builder: Create an AuthnRequest or LogoutRequest

Free tool

SAML Request Builder: Create an AuthnRequest or LogoutRequest

A SAML request builder creates the message an application sends to an identity provider to start a sign-in or a sign-out. Fill in the form below and copy the XML, the redirect URL or the POST value; nothing leaves your browser.

Try it on your systems

Build the request

Choose a sign-in or sign-out request, fill in the fields and select Build request. To see a complete set of values first, select Fill in an Acme example.

Which message to build Sign-in request (AuthnRequest) Sign-out request (LogoutRequest)

Application entity ID (Issuer) required

Identity provider single sign-on URL (Destination) required

Assertion consumer service URL required

NameID format

RelayState (optional)

Sign-in options

Force re-authentication (ForceAuthn) Do not show a login page (IsPassive) Allow the identity provider to create the identifier (AllowCreate)

Requested authentication method

How strictly to match it

Private by design. The request is built in this page and nothing is uploaded. It is not signed: a request carries no secret, and signing needs a private key that you should never paste into a web page. An identity provider that requires signed requests will refuse it.

Everything runs in this page and nothing is uploaded. The request is not signed, because signing needs a private key that never belongs in a web page.

What a SAML request is

A SAML request is the first message of a SAML sign-in. The application (the service provider) sends an AuthnRequest to the identity provider, which signs the person in and replies with an assertion. This SAML request builder produces that message from an entity ID and two URLs, so you can test an identity provider before the application is ready.

Most online SAML tools only decode messages. This one does three things:

Builds the request. It produces the message from an entity ID and two URLs.
Shows three forms. The same message appears in the three forms an identity provider accepts.
Checks the values. It checks the values that usually cause a refusal.

What the builder produces

Output	What it is	Use it to
XML	The `AuthnRequest` or `LogoutRequest` with a fresh `ID` and the current `IssueInstant`	Read the message, or paste it into a test client
HTTP-Redirect URL	The XML compressed with DEFLATE, base64-encoded and URL-encoded as `SAMLRequest`, plus `RelayState`	Open it in a browser to start a test sign-in
HTTP-POST value	The XML base64-encoded, without compression	Fill the `SAMLRequest` field of a form that posts to the identity provider
HTML form	A ready form with the value in a hidden field	Test the POST binding from a local page

The redirect URL follows the DEFLATE encoding in section 3.4.4.1 of the SAML bindings specification: compress the XML, base64-encode it, then URL-encode it. The POST value skips the compression step.

What each field sets

Application entity ID becomes the Issuer. The identity provider looks it up among its registered applications, so it must match the registered value character for character.
Identity provider URL becomes Destination. Use the single sign-on URL for a sign-in and the single logout URL for a sign-out.
Assertion consumer service URL becomes AssertionConsumerServiceURL. The identity provider normally accepts only a URL listed in the application’s metadata. Check the list with the SAML metadata checker.
NameID format goes into NameIDPolicy, or into the NameID of a logout request. It asks for the identifier type the application expects.
Force re-authentication sets ForceAuthn="true". The identity provider must ask for credentials again even if the person has a session.
Do not show a login page sets IsPassive="true". The identity provider must answer without any user interface, and returns an error if the person is not already signed in.
Requested authentication method adds a RequestedAuthnContext with the comparison you choose: exact, minimum, better or maximum.
RelayState is returned unchanged with the response. The specification limits it to 80 bytes, and the builder flags a longer value.

ForceAuthn and IsPassive cannot both be true. One demands a login and the other forbids showing one, so the builder reports the pair as an error.

Send the request and read the answer

Build a request and open the HTTP-Redirect URL. The identity provider shows its sign-in page.
Sign in. The identity provider posts a SAMLResponse to the assertion consumer service URL you entered.
Copy that response from the browser’s Network tab, or use the SAML tracer to decode it.
Check that InResponseTo equals the request ID shown under the XML, and that Destination and Audience match your values.

If the identity provider shows an error instead of a login page, compare its message with the checks under the builder. Three causes account for most refusals:

Entity ID. An unregistered entity ID.
ACS URL. A mismatched assertion consumer service URL.
Signing. An unsigned request to an identity provider that requires signing.

The SP-initiated and IdP-initiated SSO page shows where each step happens.

Use it with SSOGEN as the identity provider

SSOGEN is a SAML 2.0 identity provider that many applications can trust at once. To test an application against it:

Register the application first with the register a SAML application guide.
Enter the same entity ID and assertion consumer service URL in this builder.
Paste the SSOGEN single sign-on URL from the application’s connection details.
Open the redirect URL.

What is the difference between identity provider and service provider in SAML?

The service provider is the application a person wants to open. The identity provider is the system that signs the person in and vouches for them. The application sends a request; the identity provider answers with a signed assertion about the person.

How to run a SAML trace?

Open the browser’s Network tab with Preserve log on, start the sign-in, and find the request that carries a SAMLRequest or SAMLResponse parameter. Copy the value into a decoder such as the SAML tracer on this site. Read the issuer, destination, audience, times and status.

What is OAuth vs SAML?

SAML signs a person in to an application with an XML assertion and suits browser single sign-on in enterprises. OAuth 2.0 authorizes an application to call an API with an access token, and OpenID Connect adds sign-in on top of it. They solve different problems and often run together.

Is SAML better than LDAP?

They do different jobs. LDAP is a directory protocol that stores accounts and checks passwords, usually on a network the application can reach. SAML carries a completed sign-in from an identity provider to a web application without sharing the password. Many identity providers use LDAP behind SAML.

Where to go next

Decode. Decode the answer with the SAML tracer and decoder.
Check. Check metadata with the SAML metadata checker.
Build. Build it with the SAML metadata generator.
Overview. The overview of related tools is on the free SSO tools page.
Protocol. The protocol is explained in what is SAML.

Sources, all read 2026-10-27: SAML 2.0 bindings specification (sections 3.4.3 and 3.4.4.1); SAML 2.0 core specification.