zlacker

I'd never heard of SAML before. Is it like a more complicated version of OAuth?

>>tobinf+(OP)
Basically, yes. Give me a choice between SAML and OIDC, and I'll choose OIDC every single time.

>>tobinf+(OP)
SAML has been around longer and handles AuthN and AuthZ

OAuth only does AuthZ. I've always found OAuth more complicated because you have to combine it with other technologies to get AuthN

>>kube-s+s2
For those like me who had never heard these abbreviations:

AuthN: Authentication (who you are) AuthZ: Authorization (what you are allowed to do)

>>kube-s+s2
OpenID Connect is the standardized AuthN process built on top of OAuth. It’s “on top of” but in practice it’s a simplification if OAuth for the specific purpose of AuttN

>>thinkh+h6
I know, I just personally find it to be a fragmented and confusing set of standards. And a lot of people say OAuth when they mean OpenID Connect, which doesn't help with the confusion... or they abbreviate OpenID Connect as "OpenID" which also means something else.

I've never had to clarify what someone is actually trying to accomplish when they want "SAML 2.0"

>>kube-s+B7
You said "OAuth only does authz and must be combined with other technologies to get authn"; obviously, that's not true, in the sense that you can simply use OIDC --- a dialect of OAuth --- to get both.

Since OIDC is better than SAML, which is probably the scariest security standard on the Internet, I think it's worth being clear to people that OIDC/OAuth is viable.

The SAML authz story, for what it's worth, is pretty shady.

>>tobinf+(OP)
SAML is the de facto standard single sign-on protocol for enterprise-grade applications. If a SAAS app integrates directly with Okta or OneLogin, it probably does so with SAML.

There's a lot of functional overlap between SAML and OIDC/OAuth, but SAML is a very different (and idiosyncratic) protocol; the "what" is the same, but the "how" is very different.

>>tptace+F9
For sure. I never said SAML was any good -- I said I found it to be simpler. :)

>>kube-s+7c
For developers, they're both just libraries. As protocols to implement, SAML is drastically harder.

>>tobinf+(OP)
SAML is pretty simple, it just uses XML which I think turns people off to it by default. I've implemented it once and I feel like I have a decent handle on what it is (though maybe I've just avoided the worst edge cases).

OAuth is way more complex, I've used it countless times and still get confused by it. It has more complex patterns like having a separate resource server and authentication server, it's used for more purposes, e.g. sometimes for API access and sometimes for login and sometimes a confusing mix of both, and there are big differences between v1 and v2 and some services are still using v1.

>>cactus+vg
> SAML is pretty simple, it just uses XML which I think turns people off to it by default. I've implemented it once and I feel like I have a decent handle on what it is (though maybe I've just avoided the worst edge cases).

I once tried to implement it, and found that the specification was spread across ~500 pages of dense PDFs. I find it to be complex.

>>recurs+xu
Well, relatively simple. If you added up the number of pages in the specs for http, html, css, ecmascript, and all the various apis that web developers use every day it would likely be hundreds of thousands, maybe millions of pages. That doesn't seem like a particularly useful metric, because you don't have to read and understand the entire spec to use a technology.