Open in app

Sign in

Write

Sign in

SSO -Overview of Protocols

Mine Kaya
BosphorusISS
Published in
5 min readMay 8, 2024

Single Sign-On (SSO) basically means using the same username and password for various applications. There is one source of truth for identity management, and all other applications rely on that service. When you sign in to Gmail, you also sign in for YouTube, Analytics, etc. This is what SSO does; there is one auth service that Google apps are using. If you want to reach one and prove your credentials one time, by passing through the auth service here, you now have access to all apps that it provides.

After a basic explanation of SSO, let’s dive into the protocols that are commonly used for making this magic trick, SAML and OIDC.

SAML (Security Assertion Markup Language)

The Security Assertion Markup Language (SAML) protocol is an XML-based framework for authentication and authorization. SAML uses an XML document called an Assertion that the Identity Provider sends to the Service Provider. Before we continue, we need to understand this terminology.

  • IdP (Identity Provider) => Identity store or auth service. (This is the place that hold users)
  • SP (Service Provider) => App that user want to access. (When user wants to reach SP will ask IdP for verification)
  • SAML Request => SP requests to IdP (I need xyz about ‘this’ user )
  • SAML Response => IdP’s response to SP’s request (This is not our user or here is the xyz about the user)
  • Assertion => SAML Certificate to use for validate user (Signed via DSig (XML Signature))
  • ACS URL => Assertion Consumer Service (Url for sending SAML Response, its in SP. Assertion is validating here)
  • Attributes => User’s information, SP asks IdP sends (the xyz above)
  • Relay State => Where the user was on SP before going to IdP for verification
  • EntityID => Service Provider’s Id (for IdP to know which app sending this assertion)

It is not as complicated as it sounds, so do not worry. The IdP (Identity Provider) and SP (Service Provider) communicate via SAML Request and Response, and there is an Assertion in the response that says, “Here is your information, I signed it so you can trust it,” and this is sent to the ACS (Assertion Consumer Service) URL.

There is 2 ways to start the autharization flow , IdP-init or SP-init.

IdP-Init (Identity Provider Initiated)

Imagine that there is an app portal for your organization. You can see the list of applications that you can access, and you can choose one without needing to enter your credentials again. What’s happening here is that, before you wanted to access the application (SP), you already proved your credentials at some point. You started from the IdP first and got your Assertion. That means when you go to the SP with your Assertion, there is no need to go back to the IdP anymore.

(This means you need to have a portal or smth like that to start form IdP )

SP-Init (Service Provider Initiated)

This is the flow that we usually see in authentication processes. The user wants to access an application (SP) and needs to verify her credentials. She is redirected to the IdP, where she authenticates and receives her Assertion. Then, she goes to the SP with her Assertion and is good to go.

As I mentioned before, SAML is XML based. You can follow through with tags, <ds:Signature> where is the signature, <saml:AttributeStatement> where we can find the attributes about the user etc

SAML Request:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="pfx41d8ef22-e612-8c50-9960-1b16f15741b3" Version="2.0" ProviderName="SP test" IssueInstant="2014-07-16T23:52:45Z" Destination="http://idp.example.com/SSOService.php" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs">
  <saml:Issuer>http://sp.example.com/demo1/metadata.php</saml:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <ds:Reference URI="#pfx41d8ef22-e612-8c50-9960-1b16f15741b3">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
        <ds:DigestValue>yJN6cXUwQxTmMEsPesBP2NkqYFI=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>g5eM9yPnKsmmE/Kh2qS7nfK8HoF6yHrAdNQxh70kh8pRI4KaNbYNOL9sF8F57Yd+jO6iNga8nnbwhbATKGXIZOJJSugXGAMRyZsj/rqngwTJk5KmujbqouR1SLFsbo7Iuwze933EgefBbAE4JRI7V2aD9YgmB3socPqAi2Qf97E=</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQQFADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcwMDI5MjdaFw0xNTA3MTcwMDI5MjdaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7vU/6R/OBA6BKsZH4L2bIQ2cqBO7/aMfPjUPJPSn59d/f0aRqSC58YYrPuQODydUABiCknOn9yV0fEYm4bNvfjroTEd8bDlqo5oAXAUAI8XHPppJNz7pxbhZW0u35q45PJzGM9nCv9bglDQYJLby1ZUdHsSiDIpMbGgf/ZrxqawIDAQABo1AwTjAdBgNVHQ4EFgQU3s2NEpYx7wH6bq7xJFKa46jBDf4wHwYDVR0jBBgwFoAU3s2NEpYx7wH6bq7xJFKa46jBDf4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQCPsNO2FG+zmk5miXEswAs30E14rBJpe/64FBpM1rPzOleexvMgZlr0/smF3P5TWb7H8Fy5kEiByxMjaQmml/nQx6qgVVzdhaTANpIE1ywEzVJlhdvw4hmRuEKYqTaFMLez0sRL79LUeDxPWw7Mj9FkpRYT+kAGiFomHop1nErV6Q==</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
  <samlp:RequestedAuthnContext Comparison="exact">
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

SAML Response :

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
  <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="pfxa3ade580-86dc-2817-1a08-002b2d024e47" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
    <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
  <ds:Reference URI="#pfxa3ade580-86dc-2817-1a08-002b2d024e47"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>kVwTtNGWYO70A8e/j8dVjEPVOhM=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>HBqpd9zgR5knBJzJ/Ue+QyLSHuqBrYGMz3GpXeIKyk2s3Hg7WBIq8Xf7w2EQk9ijF8TV3FEhFjguSQ+0WlOi5Vpy0PU0KsiPtLkH0UYeF7nUP0dlWzkpxIwTRkJOYA7jas1J1mUNvjCGZTj+7FipvtCK4nyz6bRzwMNfP/5rV14=</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQ0FADBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcxNDEyNTZaFw0xNTA3MTcxNDEyNTZaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZx+ON4IUoIWxgukTb1tOiX3bMYzYQiwWPUNMp+Fq82xoNogso2bykZG0yiJm5o8zv/sd6pGouayMgkx/2FSOdc36T0jGbCHuRSbtia0PEzNIRtmViMrt3AeoWBidRXmZsxCNLwgIV6dn2WpuE5Az0bHgpZnQxTKFek0BMKU/d8wIDAQABo1AwTjAdBgNVHQ4EFgQUGHxYqZYyX7cTxKVODVgZwSTdCnwwHwYDVR0jBBgwFoAUGHxYqZYyX7cTxKVODVgZwSTdCnwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOBgQByFOl+hMFICbd3DJfnp2Rgd/dqttsZG/tyhILWvErbio/DEe98mXpowhTkC04ENprOyXi7ZbUqiicF89uAGyt1oqgTUCD1VsLahqIcmrzgumNyTwLGWo17WDAa1/usDhetWAMhgzF/Cnf5ek0nK00m0YZGyc4LzgD0CROMASTWNg==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>
    <saml:Subject>
      <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-01-18T06:21:48Z" Recipient="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z">
      <saml:AudienceRestriction>
        <saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

My honest opinion is that SAML is a bit ugly. It can be very secure, of course, if you are willing to write your custom SAML Assertion Validation tool and XML Parser. But if there is no strict requirement to use SAML, I will not. :)

OIDC (OpenID Connect)

OIDC is a simple identity layer on top of the OAuth 2.0 protocol.

If you unfamiliar with OAuth, I will recommend you read one of my previous post. But for this one, I assume you know it.

While OAuth 2.0 is about resource access and sharing, OIDC is about user authentication. OIDC uses JSON web tokens (JWTs), which you can obtain using flows conforming to the OAuth 2.0 specifications. JWTs contain claims, which are statements (such as name or email address) about an user. The OpenID Connect specification defines a set of standard claims.

resource of the image

Here is the Authorization Code flow for OAuth2. What client get as a response from Authorization Server (step D) was looks like:

{
  "access_token" : "some_jwt",
  "refresh_token" : "some_jwt",
  "expires_in" : 3600,
  "token_type" : Bearer
}

And the user could access protected resources with this access token. Now imagine that in the same step, the Authorization Server returns one more token called an id_token. Now the response looks like:

{
  "id_token" : "some_jwt",
  "access_token" : "some_jwt",
  "refresh_token" : "some_jwt",
  "expires_in" : 3600,
  "token_type" : Bearer
}

After we receive our id_token and decode it, we will get user information:

{ 
  "iss": "http://my-domain.auth.com", 
  "sub": "auth|123456", 
  "aud": "1234abcdef", 
  "exp": 1311281970, 
  "iat": 1311280970, 
  "name": "Jane Doe", 
  "given_name": "Jane", 
  "family_name": "Doe",
  ....
}

Again, my honest opinion is that OIDC (OpenID Connect) is secure enough and far easier to implement. Also, since the flow is based on JSON rather than XML, it is more mobile-friendly.

I hope you enjoyed it! (Go OIDC, booo SAML!)

Sso
Saml
Oidc
Authentication
Authorization

--

--

Mine Kaya
BosphorusISS

Written by Mine Kaya

49 Followers
Writer for

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams