Hacker News new | ask | show | jobs
by hirsin 1778 days ago
The Enterprise Apps section is heavily SAML based, but if you want to look up how to write an app for AAD you won't likely find any SAML docs, you'll find the OIDC docs and oauth SDKs we build. If you see other places where you feel we default to SAML, I'd love to fix that.
1 comments
throwaway984393 1777 days ago
Probably the wrong person to ask, but it would be great if there were guides on replacing SAML with OIDC, if you're already using AzureAD. Our architects are so f'ing clueless they're still telling us to use SAML rather than OAuth2/OIDC to integrate our apps with AzureAD. But if there was an official guide, I could send an e-mail blast to a few higher-ups and say "SAML is teh suck, but here is MS's guide on upgrading to OIDC, it's easy, no more excuses plz kthx"
link
hirsin 1777 days ago
Very much so the right person to ask! This is great to hear that there's a need for this. I think our mental model of a lot of enterprises is that "old code" stays SAML and new code (that isn't copy paste from old) is OIDC. If there's actual desire to migrate apps between the protocols, that's great. Can't promise easy though given the diversity of starting places. Thanks!
link
throwaway984393 1777 days ago
Actually our tendency is to re-use the old solution on the new code if it provides the same functionality. We still have people trying to use LDAP because nobody wants to take the time to learn something new. A migration guide makes it much more likely that they'll make an attempt to use the new thing.

Our desire to upgrade pretty much only comes from Architects telling us "thou shalt follow my shiny new standard" (and by the way, they read your docs; if you suggest SAML be dropped, they'll update their standards!). In that case we have to find time to upgrade, and of course we never just document how to do it once for our whole org, so all these engineers will be wasting time re-learning how to do the same upgrade. I'll bet you we'd save hundreds to thousands of hours per year by having really good migration docs. Even if your migration guide doesn't cover everything, they still take a significant chunk out of the time we need to figure it all out, and it lowers the mental barrier to the change.

link