SAML 2.0 works similar like OAuth 2.0 with OpenID Connect (OIDC) on top as described in my following post.

How OAuth 2.0 and OpenID Connect works


SAML primarily is designed to authenticate a user and provide the identity data in form of an identity token named SAML assertion or SAML token to an HTTP service named service provider (SP) or relying party (RP).

Further by including the Authorization Decision Assertion statement in this SAML assertion, you can also achieve authorization with SAML.

In OAuth 2.0 which is used dedicated for authorization, you can also achieve authentication to get the identity data about a user by using OpenID Connect (OIDC) extension on top of OAuth 2.0.

OAuth 2.0 is a newer framework finalized in 2012 and meanwhile the de facto industry standard for online authorization. SAML 2.0 in contrast the latest version is from 2005.

Both SAML 2.0 (Security Assertion Markup Language) and OAuth 2.0/OIDC are frameworks used to exchange authentication and authorization identities between security domains.

Security domains in this context are the following participants in a SAML 2.0 authentication and authorization flow:

  • Identity Provider (IdP) or Relying Party (RP) -> System which authenticates a user and issued a SAML assertion (token) to the user. IdP is also used in OAuth/OIDC terminology side by side with authorization server.
  • Service Provider (SP) or Asserting Party (AP) -> The HTTP application/service the user wants to access. In OAuth/OIDC terminology this is the resource server or API.
  • Client -> only used in OAuth/OIDC terminology but not with SAML. Do not mix up Client with User Agent (browser) in this context here!

    In SAML you do not authorize the application (Delegation), to which the user wants to sign in directly, named Client in OAuth terminology, to access on behalf of this user a further HTTP service named resource server or API in OAuth. With SAML you authenticate and authorize the user itself to access the service provider (HTTP application/service).

    About Using SAML for API Access and Delegation you will find more information about in the following article:

Using SAML for API Access and Delegation
https://www.identityserver.com/articles/why-you-wouldn-t-use-saml-in-a-spa-and-mobile-app


The exchange of these authentication and authorization identities is done by using a SAML assertion, which is a XML document where the identity provider (IdP) sends to the service provider (SP). The SAML assertion contains all information which is needed by the service provider (SP) to confirm the user identity, source of the assertion, issued time by the IdP and the permissions (authorization) for the service itself.

SAML 2.0 assertions
An assertion is a package of information that supplies zero or more statements made by a SAML authority. SAML assertions are usually made about a subject, represented by the <subject> element. The SAML 2.0 specification defines three different kinds of assertion statements that can be created by a SAML authority. All SAML-defined statements are associated with a subject. The three kinds of statements defined are as follows:

Authentication Assertion: The assertion subject was authenticated by a particular means at a particular time.
Attribute Assertion: The assertion subject is associated with the supplied attributes.
Authorization Decision Assertion: A request to allow the assertion subject to access the specified resource has been granted or denied.

Source: https://en.wikipedia.org/wiki/SAML_2.0#SAML_2.0_assertions

The process of exchanging these information is also named flow as in OAuth.

SAML supports here two different types of flows, one which is initiated by the service provider (SP) and commonly used and one initiated by the identity provider (IdP).


SAML Flow SP initiated


  1. Accessing the HTTP Service (SP) from the user’s browser
  2. Service Provider (SP) responds SAML request back to the user’s browser with a redirect URI pointed to the IdP
  3. User’s Browser send the SAML request to the IdP
  4. User have to authenticate against the IdP
  5. IdP generates SAML assertion (token) and sends it back to the user’s browser with a redirect URI pointed to the IdP
  6. Browser sends SAML assertion (token) back to the service provider (SP)
  7. User is logged in to the service provider (SP)
  8. user requests access and data from the service provider (SP)
  9. Service Provider (SP) responds with the requested resource to the user’s browser




Links

Single Sign-On SAML protocol
https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol

How the Microsoft identity platform uses the SAML protocol
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-protocol-reference

Glossary of Terms for SAML
https://docs.akana.com/cm/saml/08_glossary.htm

SAML 2.0
https://en.wikipedia.org/wiki/SAML_2.0

SAML
https://developer.okta.com/docs/concepts/saml/

SAML vs OAuth
https://auth0.com/intro-to-iam/saml-vs-oauth/

Authentication vs. Authorization – Part 2: SAML and OAuth
https://www.axiomatics.com/authentication-vs-authorization-part-2-saml-and-oauth-2/

Using SAML for API Access and Delegation
https://www.identityserver.com/articles/why-you-wouldn-t-use-saml-in-a-spa-and-mobile-app