SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) are the most widely used federation protocols for web based single sign-on. In the case of SAML, the most commonly used flow is Redirect/POST Bindings (SP or IDP initiated) and in the case of OIDC, it is Authorization code flow.
The below diagram depicts these 2 flows. It shows the control flow when a user tries to login to a application (SP — sp.example.com) using a SAML or a OIDC flow.
I am also planning to publish videos on the basics of SAML and OIDC in YouTube channel. Please subscribe to this channel.
SAML vs OIDC Response
Below is an example of a sample SAML <Response> and OIDC idtoken for the same user authenticated using the same IDP.
Sample SAML Response:<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="s20a470b3a4be603e0ddb4b6db20a66765ab18da3d"
InResponseTo="s280b6ec55cc58adafa481657243b780fdad02af0e"
Version="2.0"
IssueInstant="2018-07-10T17:14:53Z"
Destination="http://sp.example.com:9080/sp/AuthConsumer/metaAlias/idpproxy/sp"
>
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://openam.example.com:8080/idpam</saml:Issuer>
<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Value="urn:oasis:names:tc:SAML:2.0:status:Success"
/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="s2044666918b0c3db0bfa6bc84f54bbc997472272c"
IssueInstant="2018-07-10T17:14:53Z"
Version="2.0"
>
<saml:Issuer>http://openam.example.com:8080/idpam</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="#s2044666918b0c3db0bfa6bc84f54bbc997472272c">
<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>R4YFpd+ZTx6ca50yVs7bH4Ehse8=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
Fare7CvWrv9HXC0C2RWA56AKKzR6kyj0dxiyOwNPp/V07CANOnGI14lmiWgZvyRa1KkiFU5l+KZf
9Tp/TZfCSEXNnsEwqiaw6rqBQSY6C4NjxvT14XhNwLnN9v7Q+3EZvo2fnfEx1PFopQTCxvGKBL8X
rHDKHPGkDDvcTeVwTsAA1tJukowkNVdQ4ubmRcrULYw6MSwwWp/f76Rvm+v1TZNScAOTIAEpkP01
4C1s0ZNpyM2XG88KWmaxd69tySDYWUocqfNlDFFmohWsasRfFv9HV7WLLPXy8w0ndnDEjX4FDGfm
wQLv64EintY/P/hcLH7fiTLKgsNDHMctlUKq0g==
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIDaDCCAlCgAwIBAgIDcB/YMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYTAlVLMRAwDgYDVQQI
EwdCcmlzdG9sMRAwDgYDVQQHEwdCcmlzdG9sMRIwEAYDVQQKEwlGb3JnZVJvY2sxDzANBgNVBAsT
Bk9wZW5BTTENMAsGA1UEAxMEdGVzdDAeFw0xNjAzMTgxMTU2MjhaFw0yNjAzMTYxMTU2MjhaMGUx
CzAJBgNVBAYTAlVLMRAwDgYDVQQIEwdCcmlzdG9sMRAwDgYDVQQHEwdCcmlzdG9sMRIwEAYDVQQK
EwlGb3JnZVJvY2sxDzANBgNVBAsTBk9wZW5BTTENMAsGA1UEAxMEdGVzdDCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAKNbl89eP6B8kZATNSPe3+OZ3esLx31hjX+dakHtPwXCAaCKqJFw
jwKdxyRuPdsVG+8Dbk3PGhk26aJrSE93EpxeqmQqxNPMeD+N0/8pjkuVYWwPIQ/ts2iTiWOVn7wz
lE4ASfvupqOR5pjuYMWNo/pd4L7QNjUCKoAt9H11HMyiP+6roo/EYgX4AH7OAhfUMncYsopWhkW/
ze9z8wTXc8BAEgDmt8zFCez1CtqJB/MlSBUGDgk8oHYDsHKmx05baBaOBQ8LRGP5SULSbRtu34eL
FootBIn0FvUZSnwTiSpbaHHRgWrMOVm07oSLWBuO3h/bj38zBuuqqVsAK8YuyoECAwEAAaMhMB8w
HQYDVR0OBBYEFHxfAbr6PQ5Xgc+jVx+AGTPnnpWZMA0GCSqGSIb3DQEBCwUAA4IBAQAZBMJ29/2i
dv1ztC6ArHtB4kw/nHHwthXFwtWAN7sRPB8tLW7fD8aJ43RQr5107Bg1Lgkmt+FZxpafqUC/mukj
IzGzbW0COMSOTcWUGss+HxK6M6Fl9aOzKJMct1uOSpPFgjItcGqydGZXR2FH93vXWoAotUwtZ119
IixIdxpOJwYJg0HFn+GEfpU1PmiLfq2/uwqJ0hGCNfNcm9puagzhQrcDFOnolxjnYPSfSkU5wxlG
o99yE5eJwoHXXU7csaZVttmx7sPj1lUENogXUM6JMqzSyEIm1XCOCL8rZJkZ781W5CwZhuJTNzV3
1sBREs8FaaCeksu7Y48BmkUqw6E9
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
NameQualifier="http://openam.example.com:8080/idpam"
SPNameQualifier="http://sp.example.com:9080/sp"
>idpuser1</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="s280b6ec55cc58adafa481657243b780fdad02af0e"
NotOnOrAfter="2018-07-10T17:24:53Z"
Recipient="http://sp.example.com:9080/sp/AuthConsumer/metaAlias/idpproxy/sp"
/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2018-07-10T17:04:53Z"
NotOnOrAfter="2018-07-10T17:24:53Z"
>
<saml:AudienceRestriction>
<saml:Audience>http://sp.example.com:9080/sp</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2018-07-10T17:14:53Z"
SessionIndex="s2e2a25b53c0481abeac81738eb2fd49c164856201"
>
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="uid">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>idpuser1</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="sn">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>user</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="cn">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>IDP user modified</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="mail">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>idpuser@example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="givenname">
<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string"
>ipd</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
Sample OIDC idtoken:eyAidHlwIjogIkpXVCIsICJhbGciOiAiSFMyNTYiIH0.eyAiYXRfaGFzaCI6ICJ1OTFrRE15OUlWVFMzRjYwMEpyeG5BIiwgInN1YiI6ICJpZHB1c2VyMSIsICJhdWRpdFRyYWNraW5nSWQiOiAiYWRhNzNhODQtMzNjMi00MTUyLWJjY2YtNjYxY2NjZDUxNGVmLTkyIiwgImlzcyI6ICJodHRwOi8vb3BlbmFtLmV4YW1wbGUuY29tOjgwODAvaWRwYW0vb2F1dGgyL2lkcHByb3h5IiwgInRva2VuTmFtZSI6ICJpZF90b2tlbiIsICJnaXZlbl9uYW1lIjogImlwZCIsICJub25jZSI6ICI2Nzg5IiwgImF1ZCI6ICJ0ZXN0YWdlbnQiLCAiY19oYXNoIjogInY1ai1ZWExQNklic1NpVDh0ZW82dlEiLCAib3JnLmZvcmdlcm9jay5vcGVuaWRjb25uZWN0Lm9wcyI6ICJlOGI2NmI4ZS05YTFmLTRlNmUtOGNjZi03MTI5Yjk1NmEyY2YiLCAiYXpwIjogInRlc3RhZ2VudCIsICJhdXRoX3RpbWUiOiAxNTMxMzI2NjE2LCAibmFtZSI6ICJJRFAgdXNlciBtb2RpZmllZCIsICJyZWFsbSI6ICIvaWRwcHJveHkiLCAiZXhwIjogMTUzMTMzMDI0OCwgInRva2VuVHlwZSI6ICJKV1RUb2tlbiIsICJpYXQiOiAxNTMxMzI2NjQ4LCAiZmFtaWx5X25hbWUiOiAidXNlciIgfQ.dK0LuBmH2ZdH4BuA6M3T3-9lEq20LDvqpm-CQ7sl7dQ
SAML vs OIDC Token
Below is an explanation of the key elements or attributes in SAML <Response> and OIDC id_token.
Which one to use — SAML or OIDC?
- SAML is one of the most widely used federation protocol for web browser single sign-on. Even today, all the latest COTS products and SaaS providers support SAML integration for providing SSO access to the end users.
- OIDC is also being used widely in many single sign-on use cases. Some of the services like say AWS Cognito support only OIDC integrations even though they provide options to federate with a remote IDP using SAML or OIDC.
- SAML is basically heavy weight due to the size of the XML messages that is being transmitted to and fro between the SP and IDP whereas OIDC is pretty light weight.
- SAML specification doesn’t have a user consent flow even though it can be built in the login flow. OIDC specification expects the user to provide consent to share their profile details which meets all the latest privacy regulations like GDPR.
- SAML token (Assertion) is generally not meant for API security. In the case of OIDC, a SP gets an Access and Refresh token in addition to the id_token. With most of the modern API security architecture supporting OAuth2 scopes, OIDC is the preferred protocol since it is built on top of OAuth2 authorization protocol. So, OIDC basically satisfies both Authentication and Authorization use cases.
- With more and more focus on mobile apps and service oriented architecture, OIDC is being widely used for Authentication and Authorization due to lightweight and REST based architecture.
- A combination of OIDC and OAuth2 protocols can be used for various use cases like machine-to-machine authentication, device authentication etc. whereas SAML is not preferred for these use cases.
- Ideally, organizations are going to use both SAML as well as OIDC depending on the use case.
Other blogs that might be of interest :
Thanks for reading this article. If you have any questions/suggestions, kindly leave a comment.
