Help: Single Sign-On setup with Okta is failing.

Ah, the classic "Authentication Failed" black hole - been there! Since the tracer shows the response is sent, I'd bet my morning coffee it's one of two things.

First, the Name ID value. You've got the format as EmailAddress, but double-check the actual value Okta is sending in the assertion matches the exact email of the user's account in Ideogram. A trailing space or mismatched case can break it.

Second, and this got me last year, is that X.509 cert. Make absolutely sure you copied the full certificate from Okta, including the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" lines, and pasted it into Ideogram's IdP metadata field with no extra characters. A single stray line break will cause this exact silent fail.

Maybe also try setting the Application username in Okta to 'Okta username' instead of 'Email' temporarily, just to rule out a mapping conflict. Sometimes the SP expects the Name ID to be the persistent user ID, not the email attribute.

You're right to suspect the assertion mapping. Since the response is being sent, IdP config is likely fine.

Double-check the audience URI in Ideogram matches your Okta ` https://app.ideogram.ai` exactly, no trailing slash. That mismatch is a silent killer.

Also, set the Name ID value in Okta's SAML settings to `${user.email}` and force it to be Unspecified format, not EmailAddress. Some SPs are picky about that.

I've seen the "force to Unspecified" trick work more times than I can count, especially with SaaS vendors who use off-the-shelf SAML libraries. The rigid `EmailAddress` format can cause a mismatch on the SP side's string parser.

But a word of caution on `${user.email}`. If you have users with non-standard email formats, or if your Okta directory's primary email field isn't populated consistently, you'll just trade one error for another. Always verify the attribute value in the SAML response itself matches the *username* field the service provider expects, which isn't always the user's main email. I've had cases where the SP wanted the username from our internal directory, not the email, and using `${user.login}` was the actual fix.

Agree on the audience URI, that's a common one. But forcing the format to Unspecified isn't a magic fix - it just removes Okta's formatting. The real issue is the value mapping itself.

The key is what Ideogram expects as the principal. Check their SP metadata or support docs for the required NameID format. Sometimes it's `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress` and they reject Unspecified. The tracer will show you exactly what's being sent.

Also, verify the clock skew. A mismatch of more than a few minutes between Okta and Ideogram's servers will invalidate the assertion.

Good point on the certificate. I've seen deployments fail because the cert was pasted from a PDF, which added invisible formatting characters. Always copy from the plain text view in the Okta admin console.

Your mention of the Application username setting is also critical. If the SP is configured for email but Okta sends the login, it'll fail silently. I always test with a single user first, switching that mapping to isolate the variable.

Copying from a PDF is a rookie move, but the plain text view in Okta can still include line wrapping that breaks the cert. I always open the browser dev tools and copy the raw text from the network response for the metadata URL.

Testing with a single user is the only sane approach. But isolating the variable only helps if you know what the SP actually expects. Their docs are usually wrong. You have to guess based on the error logs they won't show you.

That generic "Authentication Failed" is the worst, isn't it? It feels like a dead end.

Since the SAML tracer shows the response is sent, I agree it's likely mapping. But everyone's fixated on the NameID format. Have you actually checked what Ideogram expects? Their docs might say email, but sometimes the actual app uses a username or an internal ID. The format might be right, but the value could be wrong.

Also, you said you mapped the user's email to `email`. That's for attribute statements, right? Is the SAML response actually *showing* a value for that `email` attribute in the tracer? I got burned once where the mapping looked right in Okta but the attribute was missing from the outgoing assertion entirely because of a filter rule.

Yes, that's such a good point about the attribute mapping! It's so easy to assume it's configured just because you've typed it in. The SAML tracer showing the attribute is actually *present* in the response is a critical, often missed, step.

>because of a filter rule.

This is a sneaky one. An Okta group rule or profile filter might be stripping the attribute out before it even gets to the app assignment. I've spent hours staring at the "Attribute Statements" tab only to realize the issue was upstream in a group membership rule. 😅

Have you tried using the Okta API to dump the full user profile for a test account? Sometimes the raw data there reveals a mismatch you wouldn't see in the admin UI.

Good catch on verifying the attribute is actually present in the response. I'd run the tracer again and look for that `email` attribute specifically.

Also, I see you have the Name ID format set to EmailAddress. Try switching it to Unspecified with `${user.email}` as the value, like user278 said. That combo has unblocked me more than once.

One more quick thing - is your test user's email in Okta identical to their Ideogram login? A period or plus sign difference can cause a silent mismatch.

The trailing slash on the audience URI is such a common and infuriating footgun. It's the kind of thing that works perfectly in dev where you're using a test URL, then explodes in prod.

Your Unspecified format tip is solid, but I'll add a caveat: switching from `EmailAddress` to `Unspecified` can sometimes just move the failure from the SP to the IdP if Okta's attribute policies are strict. You need to make sure `${user.email}` actually populates reliably for the app assignment. I've seen it blank out for service accounts.

The service account point is particularly relevant, but I'd extend that to any user with a non-standard email field. The `${user.email}` expression in Okta pulls from the "Primary Email" profile attribute, but in many enterprise setups that field can be sourced from an HR system, AD sync, or can be empty for contractors. If that field is null, you get a blank NameID, which causes a cryptic failure.

A more reliable method is to map the NameID to a dedicated, guaranteed-unique attribute like an Employee ID or a sanitized username, then use attribute statements for the actual email. This decouples the unique identifier from the mail system.

You can test this by checking the "Preview SAML" tab in Okta for a known problematic user before changing the mapping.

You've covered the typical base configuration, but the devil is in the validation steps. A tracer showing the response is sent is insufficient, you must inspect the payload itself.

First, run the SAML tracer and verify these three exact values in the `` block: the NameID's Format attribute must match `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`, and the actual NameID value must be the user's email verbatim. Second, check that your `email` attribute statement appears as a `` with a `Name="email"` and the correct value.

I'd wager the issue is the NameID value mismatch. `EmailAddress` format requires a valid email address structure. If your Okta user's primary email field has a typo or is missing, the assertion fails. Use the Okta Admin API to fetch the raw user profile for your test account and compare it to what you see in the tracer.

Good setup on the surface. The generic error usually means the SAML assertion is malformed somewhere between sending and accepting.

You mentioned the SAML tracer shows the response is sent, but can you confirm the *entire* certificate is pasted correctly on the Ideogram side? The X.509 from Okta can get line breaks inserted if you copy it from certain views. I always paste it into a plain text editor first to strip any formatting before putting it in the SP config. An invalid cert there would cause an immediate "Authentication Failed."

Also, double-check the Audience URI. You have it as ` https://app.ideogram.ai`. Sometimes the SP expects the full ACS URL there, or a trailing slash. Try the exact value from Ideogram's metadata if they provided any. A mismatch here is a silent killer.