Analysis of Common Federated Identity Protocols: OpenID Connect vs OAuth 2.0 vs SAML 2.0

Introduction

Federated Identity

Single Sign-On (SSO)

Authentication vs. Authorization

OAuth 2

  • Resource owner: the user that can grant access to the protected resource
  • Client: the application that requests access to a protected resource
  • Resource Server: the server that hosts a protected resource
  • Authorization Server: the server that authorizes the client to access a protected resource
  • Authorization Code Grant Type
  • Implicit Grant Type
  • Resource Owner Password Credentials Grant Type
  • Client Credentials Grant Type
  • First, the Client (application) spawns a browser window similar to the one from Figure 1 asking for Resource Owner’s authorization to proceed further.
  • Once the Resource Owner approves the access the Client receives a verification code -a simple randomly generated string.
  • The Client requests an Access Token from Authorization Server by providing the verification code acquired in the previous step.
  • If the verification code is correct the Authorization Server generates an Access Token and sends it to the Client.
  • The Client makes an HTTP request to access the protected resource located on the Resource Server including the Access Token in the request.
  • If the Access Token is valid the Client is allowed to access the protected resource.

OAuth 2.0 vulnerabilities

Account Takeover via Open Redirect

https://login.webapp.com/oauth/authorize?clientid=123456&response_type=code&redirect_uri=https%3A%2F%2Fdashboard.webapp.com%2Fcallback
https://login.webapp.com/oauth/authorize?clientid=123456&response_type=code&redirect_uri=https%3A%2F%2Fattacker.com%2Foauth
https://dashboard.webapp.com/callback?code=victim's verification code

Mitigation

Account takeover via CSRF

https://example.com//auth/facebook/callback?code=<attacker’s authorization code>

Mitigation

Conclusion

OpenID Connect

OpenID Connect vs. OAuth 2.0

SAML 2.0

SAML Vulnerabilities

XML Signature Wrapping

SAML Authentication Bypass

  1. The attacker logs into his account (john@example.com.evil.com) and tries to access a resource.
  2. The Identity Provider generates a SAML assertion containing the user identifier (email address) and sends it back to the Service Provider.
  3. Now the attacker updates his email address in the SAML assertion, and adds an XML comment right before .evil.com: john@example.com.evil.com.
  4. Due to an XML parsing issue the SAML Processing Library ignores the comment and everything after it. Thus, the Service Provider processes john@example.com as the real email address of the attacker instead of john@example.com.evil.com.
  5. As a result, the attacker is allowed to access the protected resource on behalf of john@example.com.

Mitigation

SAML vs. OpenID Connect vs. OAuth 2

--

--

--

Co-founder and CEO of HackEDU. Previously a CISO. 15 years in cybersecurity.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Amazon Web Services (AWS) & the UK Government

Coinbase Wallet x PolyDoge

How to Transfer an eSIM from an old iPhone to a new iPhone

Why Not Stress Test Your Cybersecurity Defenses https://www.linkedin.com/pulse/why-stress-test-your-

How to Transfer Google Authenticator to New Phone

How to Transfer Google Authenticator to New Phone

{UPDATE} Corsair's Jewels Deluxe: match-3 diamonds Hack Free Resources Generator

Using Lampyre for Basic Email and Phone Number OSINT

Pythonswap Launchpad

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jared Ablon

Jared Ablon

Co-founder and CEO of HackEDU. Previously a CISO. 15 years in cybersecurity.

More from Medium

Self Signing Requests in Postman

Preserve authenticated AWS Cognito state in Playwright

RoboCon 2022: epilogue

What Are AWS CDK Constructs, Stacks and How To Use Them — Interweave