[tptacek]

We don't like TOTP, at all, for reasons even more obvious now, but our standard answer for advanced MFA has been OIDC, which is what most people should do rather than setting up bespoke U2F/FIDO2/Passkeys.

We will get to this though.

https://fly.io/blog/tokenized-tokens/

[parliament32]

That would be great, but

> Fly.io supports Google and GitHub as Identity Providers[1]

How about you just support SAML like a real enterprise vendor, so IdP-specific support isn't your problem anymore? I get it, SAML is hard, but it's really the One True Path when it comes to this stuff.

[1] https://fly.io/docs/security/sso/

[tptacek]

SAML is awful, maybe the worst cryptographic protocol ever devised, and we won't implement it unless we absolutely have to. OIDC is the future.

I'm not exaggerating; you can use the search bar and find longer comments from me on SAML and XMLDSIG. You might just as well ask when we're going to implement DNSSEC.

[grinich]

It's so bad

Here is a major vulnerability we disclosed earlier this year:

https://workos.com/blog/samlstorm

[parliament32]

I certainly see you whining a lot about SAML in your history. This lines up with my "SAML is hard" comment above -- SAML is filled with footguns and various perils, but that doesn't necessarily make it bad. OIDC is certainly better in a few aspects (note trading XML parsing for JSON parsing is not one of them), but the killer SAML feature that you (and by you, I mean fly.io, to be clear) is missing is being IdP-agnostic. You cannot reasonably expect that those two vendors will cover even half of your potential enterprise user base; and yes, for anyone working in an even remotely regulated industry, not being compatible with our SSO ensures you get dropped even before the evaluation phase.

My favourite slop-generator summarizes this as "While SAML is significantly more complex to implement than OIDC, its design for robust enterprise federation and its maturity have resulted in vendors converging on a more uniform interpretation of its detailed specification, reducing the relative frequency of non-standard implementation quirks when dealing with core B2B SSO scenarios." That being said, if your org is more B2C, maybe it makes sense you haven't prioritized this yet. You'll get there one day :)

[tptacek]

"SAML is filled with footguns and various perils" is in fact why it's bad. You don't look at an archaic cryptosystem full of design flaws and go "skills issue". The "skills issue" would be using it at all. Sorry, SAML is dead.

[x0x0]

But also too almost every vendors implementation is subtly different!