3

I'm learning SAML, which is said to be centralized. To understand the difference with decentralized, I'm reading about OpenID.

I find it difficult to understand the difference between the two, regarding centralization. OpenID is said to be decentralized because it supports multiple entities which authenticate users. But this is also the case with SAML.

What makes OpenID decentralized and SAML centralized?

Steven Volckaert
  • 1,193
  • 8
  • 15
Stefan Rasmusson
  • 426
  • 2
  • 11

1 Answers1

5

These are not really parallel technologies, but simplistically:

When you are using the SAML model, you typically respect a single issuer of SAML tokens (or perhaps a handful, but pre-defined by the service). That is, there is a single, central repository of user credentials, and all the "consumers" accept its' tokens and validate against that one.

With OpenId, you are typically accepting any OpenId provider, based on the user's input - it could be Google, or Facebook, or StackExchange, or your corporate OpenId provider, or your own home server. Either way, it doesn't matter.

This is not just a question of numbers, either. With SAML, you explicitly trust the SAML server to authenticate and verify your actual identity - which you can later rely on. With OpenId, you don't necessarily have any trust relationship with the OpenId provider - you accept whatever it tells you, and you don't actually care: you just need some form of assured identity (actually more of a "placeholder" in this case).

So, to sum up: SAML is centralized because you expect to control identities, OpenId is distributed because you have given up that control.

AviD
  • 72,138
  • 22
  • 136
  • 218
  • Ok, it seams like typically is the keyword here. Bacause with SAML you can have multiple and with OpenID you can choose to trust only one. – Stefan Rasmusson May 05 '14 at 09:53
  • You say that you dont have a trust relationship with openid providers. Isn't accepting whatever it tells you a typical trust? – Stefan Rasmusson May 05 '14 at 09:54
  • @Stefan True, you *can* change the numbers (as I mentioned), but that's not the important part - the *model* of your interaction with them is. I.e. even if you only accept one OpenID IdP, the model is still the same. As far as trust, this is really the core issue - with IdP you don't actually *trust* them to authenticate the user, you *just don't care*, and are willing to *accept* whatever they say. It's like the difference between the DMV and a local cinema: The DMV will insist on knowing for sure who you are, but if your friend says your name is John Smith, the cinema will be fine with that. – AviD May 05 '14 at 10:16
  • But how can I not care about the authentication in OpenID? I Im going to use the authenticated user in my system I must be able to trust that the OpenID provider authenticates the user correctly. Dont I? – Stefan Rasmusson May 05 '14 at 13:28
  • @Stefan and that's exactly what I mean - it is no longer your responsibility to care. Hypothetically, an IdP might not implement authentication at all, and that would still be "valid". If the IdP approves an identity, the relying party just *relies* on that. It is up to the IdP to worry about authentication. Again, you're not being assured of a "real" identity (in the meaning that would be valid for the DMV, or a bank), you are just being assured that the user is authorized to use *that* identity. – AviD May 05 '14 at 15:44
  • 1
    @Stefan also note that this is one of the inherent drawbacks of the OpenId model, and what makes it not a good fit for certain scenarios. E.g. I would not recommend a bank allow it's customers to login via OpenID. See also my answer [here](http://security.stackexchange.com/a/170/33), including the comments there. – AviD May 05 '14 at 15:48