Search code examples
oauth-2.0oauthopenid-connectsamlsaml-2.0

Limitations of SAML as compared to OAuth


I know how SAML works and I know how OAuth and OPENIDConnect works. I know that SAML is for authentication and OAuth for authorization. but in certain articles it is mentioned that when in 2007 iPhone came in SAML lacked authentication in that case ( for mobile apps ), I am unable to understand that besides delegated authorization, why we needed OAuth to tackle mobile authentication problem ( now being done by OPENIDConnect ) Or how SAML was unable to deal with that issue. can someone help resolve this confusion. Thanks


Solution

  • SAML was not designed for allowing the application to authenticate. It depends on a pre-shared key mechanism for signing/validation, encryption/decryption that is better handled at a server with the attributes being fed to the downstream app in some other manner (like OAuth or OIDC). Can you imagine needing to update a couple million app installs just because the IdP wants to rotate their certificate? Or, worse yet, the IdP's private key gets compromised? Key management in SAML is a difficult enough process, and if you fail, there's a name for the attack you are exposed to - the Golden SAML Attack.

    OAuth and OIDC, on the other hand, were designed in such a way thatthe private keys for signing and encryption are expected to rotate regularly. The public keys for decryption and validation are shared on an accessible endpoint by the Authorization Server (AS) or OIDC Provider (OP), which is publicly announced by the AS/OP in the required metadata endpoint. This makes it so that the downstream application that is using the AS/OP can get the keys it needs when they rotate. Generally, the application will cache the keys and use them until failure, at which point it goes and retrieves the new set.