WS-Trust|WS-Fed |SAML-P|OAuth|OIDC

Introduction

• Goal of these web-security standards is to enable federation between partners.
• All are used to authenticate user at IdP/ STS and get a security token (assertion) for user to access the SP (resource) across the security domains.
• All these protocols allow to build a trust relationships (using metadata exchange) between IdP and SP for a security token (assertion) exchange.
• All these protocols will talk about how to transport the tokens, mechanism to issue, sign, encrypt, convert, validate and renew security tokens. (uses XML Security)
• All these protocols uses SAML1.x or SAML2.0 as a token to exchange identity information between IdP and SP.

WS-Trust

• WS-Trust is a standard which provide extensions to WS-Security specification that defines protocols to issue, signing, encrypting, converting, validating and renewing security tokens.
• WS-Trust standard specifies how a web-client, IdP and SP are responsible in exchanging the messages + security token between them.
• In this standard, both IdP and SP are called as Secure Token Service (STS).
• On IdP side, the STS issues a SAML security token containing the user’s identity to web-client, which in turn forward to SP to access its resource.
• On the SP side, the STS validates incoming SAML security tokens from web-client and can generate a new local token for web-client to consume and access its resource.
• This protocol uses SOAP messages for communication.

WS-Federation

• WS-Federation is an extension to the functionality of WS-Trust and typically defines the transport mechanism of security tokens and used mainly for web-browser authentication.
• WS-Federation has two profiles defined:
  • Active Profile Authentication
    • Uses WS-Trust protocol to authenticate user against STS/IdP and provide the SAML security token to the web-client, which in turn submit to STS/SP (which validates the token) in exchange for a local security token between web-client and STS/SP.Typically used for thick-desktop clients.
    • For example: MS-Outlook desktop-client is a web-client, Google as an STS/IdP and Office365 as an STS/SP.
    • Username token (are embedded in SAML token and whole token is SOAP based) is widely used in active profile authentication, where user submits username/ password to web-client and it will hand over to STS/IdP for authentication for a SAML token.
  • Passive Profile Authentication
    • Uses WS-Federation protocol to authenticate user against STS/IdP and provide the SAML security token to the STS/SP (via web-browser), which validates the token in exchange for a local security token between web-browser and STS/SP.
    • Typically used for web-client such as web-browser authentication.
    • It relies on browser redirects, HTTP GET, and POST to request and pass around tokens.
    • For example: Web-browser is a web-client accessing Office365-Sharepoint App, Google as an STS/IdP and Office365 as an STS/SP.
    • Sometimes this profile is also called as Claim-Based Authentication because of SP assert the claim/ attribute present in the security token, which is sent by a trusted issuer or IdP.
    • The communication between STS/IdP and STS/SP are based HTTP query-param key-value:
      • wa: wsignin1.0, wsignout1.0, wsignoutcleanup1.0
      • wtrealm: partnerProviderID of SP or IdP
      • wctx: request context
      • wresult: SAML security token.
• The communication between STS/IdP and STS/SP are based Request Security Token (RST) and Request Security Token Response (RSTR).
  • In case of Active Profile, the RST and RSTR are SOAP based messages.
  • In case of Passive Profile, the RST is query-param (wa=wsignin1.0) and RSTR is (wresult=SAML security token).

SAML-P

• More about SAML-P, please refer this link.
• We can see that WS-Fed (Passive Profile) and SAML-P are used in web-browser authentication.
• SAML-P uses specific SAML AuthnRequest/ Response protocol message flows, along with other protocols such as Assertion Query Protocol, Artifact Protocol, Name Identifier Management Protocol, Single Logout Protocol, Name Identifier Mapping Protocol, various Bindings and Profiles. There is also lot of flexibility in handling the encryption/ signing part of message in SAML-P.
• Whereas, WS-Fed uses simple HTTP query-param request/ response style of communication between IdP and SP.

Conclusion

All these protocols looks similar, but all comes with specific use cases:

• WS-Trust: Covers use-case such as SOAP based SAML security token (RSTR) exchange for a given SOAP request (RST).
• WS-Federation: Covers use-case such as web-browser authentication with HTTP query-param request (RST) and response in query-param (RSTR).
• SAML-P: Covers use-case such as web-browser SSO with HTTP-POST, Redirect, Artifact SAML AuthnRequest/ Response message exchange with added flexibility an security in all levels of models. There by, SAML-P covers multiple use-cases than what WS-Fed offers. Please refer this link for detailed note on SAML-P.

Additional Protocols

OAuth2.0

• Authorization protocol.

OpenID Connect

• Authentication protocol.

Original OpenID 2.0 vs SAML

They are two different protocols of authentication and they differ at the technical level.

From a distance, differences start when users initiate the authentication. With OpenID, a user login is usually an HTTP address of the resource which is responsible for the authentication. On the other hand, SAML is based on an explicit trust between your site and the identity provider so it’s rather uncommon to accept credentials from an unknown site.

OpenID identities are easy to get around the net. As a developer you could then just accept users coming from very different OpenID providers. On the other hand, a SAML provider usually has to be coded in advance and you federate your application with only selected identity providers. It is possible to narrow the list of accepted OpenID identity providers but I think this would be against the general OpenID concept.

With OpenID you accept identities coming from arbitrary servers. Someone claims to be http://someopenid.provider.com/john.smith. How you are going to match this with a user in your database? Somehow, for example by storing this information with a new account and recognizing this when user visits your site again. Note that any other information about the user (including his name or email) cannot be trusted!

On the other hand, if there’s an explicit trust between your application and the SAML Id Provider, you can get full information about the user including the name and email and this information can be trusted, just because of the trust relation. It means that you tend to believe that the Id Provider somehow validated all the information and you can trust it at the application level. If users come with SAML tokens issued by an unknown provider, your application just refuses the authentication.

OpenID Connect vs SAML

This answer dates 2011 and at that time OpenID stood for OpenID 2.0. Later on, somewhere at 2012, OAuth2.0 has been published and in 2014, OpenID Connect (a more detailed timeline here).

To anyone reading this nowadays – OpenID Connect is not the same OpenID the original answer refers to, rather it’s a set of extensions to OAuth2.0.

While this answer can shed some light from the conceptual viewpoint, a very concise version for someone coming with OAuth2.0 background is that OpenID Connect is in fact OAuth2.0 but it adds a standard way of querying the user info, after the access token is available.

Referring to the original question – what is the main difference between OpenID Connect (OAuth2.0) and SAML is how the trust relation is built between the application and the identity provider:

• SAML builds the trust relation on a digital signature, SAML tokens issued by the identity provider are signed XMLs, the application validates the signature itself and the certificate it presents. The user information is included in a SAML token, among other information.
• OAuth2 builds the trust relation on a direct HTTPs call from the application to the identity. The request contains the access token (obtained by the application during the protocol flow) and the response contains the information about the user.
• OpenID Connect further expands this to make it possible to obtain the identity without this extra step involving the call from the application to the identity provider. The idea is based on the fact that OpenID Connect providers in fact issue two tokens, the access_token, the very same one OAuth2.0 issues and the new one, the id_token which is a JWT token, signed by the identity provider. The application can use the id token to establish a local session, based on claims included in the JWT token but the id token cannot be used to further query other services, such calls to third party services should still use the access token.
• You can think SAML2 (a token works for both authn/ authz purpose) and OAuth2 (an access token works authz only), as OpenID Connect (ID token works for authn only).