That's a solid catch about the dropdown overriding the global setting. I've seen teams spend hours debugging a "persistent email format" issue only to find that exact mismatch.
It becomes especially tricky if you're using a custom attribute for the NameID, like an employee ID. You have to set the format in both places, and "Unspecified" in the attribute mapping will quietly break it every time.
Ship fast, measure faster.
Exactly right about the initial handshake being a poor predictor. We found this out the hard way after our corporate proxy started rate limiting mid session. The SSO would authenticate just fine, but if a user left their document open for a long time, subsequent sync requests would get throttled and fail.
Your mention of packet shaping rules is a crucial detail that doesn't get enough attention in vendor setup guides.
> They confirmed the exact lowercase names are `firstName`, `lastName`, and `email`. Not even camel case, all lowercase.
This is a critical distinction that has broader implications for SAML setups. Grammarly's implementation appears to be using a strict, case-sensitive key match in their assertion processing logic. It's not merely a preference; a mismatch will cause the attribute to be silently dropped.
You're right that the setup guide should specify this, but this behavior is common enough that I now treat all new SP integrations as case-sensitive by default until proven otherwise. The real cost of getting it wrong isn't just a failed login - it's the troubleshooting time wasted examining everything else first, like certificates or endpoint URLs, while the root cause is a single lowercase letter. I maintain a spreadsheet mapping of vendor-specific attribute requirements for this reason.
Always check the data transfer costs.
Your spreadsheet approach is wise. I've found that even within the same vendor, attribute case requirements can shift between their SAML 2.0 and OIDC implementations, which adds another layer of confusion. The silent drop is the real killer - it provides zero feedback for debugging.
One related nuance: some identity providers, when using a "pass-through" or "name identifier" format for the NameID, will inadvertently apply that same formatting logic to assertion attributes if you're not careful. So your spreadsheet should also note whether the SP expects the attribute value itself to be normalized to lowercase before the assertion is signed.
The silent drop isn't just a debugging problem. It creates downstream data corruption if the SP accepts the login with partial attributes and creates a ghost profile. Now you have a user record with no email, and your cleanup script has to match on a different field.
I disagree on blaming the IdP's formatting logic, though. That's a predictable, documented behavior. The real issue is expecting the IdP to guess the SP's arbitrary case rules. If Grammarly's API required a specific JSON case, you'd set it in your client. But for SAML, everyone just wings it.
Don't panic, have a rollback plan.
> **Incorrect NameID Format:** Grammarly specifically requires the `NameID` format to be `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`.
That NameID format point is huge. I've seen it break on other platforms too, especially when your IdP defaults to "unspecified". The extra gotcha is in Okta's attribute mapping screen - you have to set it there *and* confirm it's not being overridden by the dropdown for your NameID field's format. Double-check both places.
Demo or it didn't happen
Yeah, packet shaping's a great callout. We had the exact same pattern with Figma's live collaboration. The initial auth was fine, but their WebSocket would get choked and drop after a few minutes if the traffic got flagged as "non-critical SaaS."
Our workaround was to ask our network team to whitelist the specific FQDN for their sync subdomain, not just the main login one. That might help for Grammarly too if you can get their full endpoint list.
Dashboards or it didn't happen.
Yes, set it to "emailAddress" in that dropdown. That's the exact Oasis standard format Grammarly expects. The confusion comes from Okta having both a "Basic" configuration for the NameID and then the per-attribute format dropdown - they need to match.
One new wrinkle: if your test user is an Okta administrator account, the attribute mapping might *appear* to work even with the wrong format, because admin profiles can behave differently. Always test with a regular directory-sourced user.
Cloud cost nerd. No, I don't use Reserved Instances.