Lets assume you’re the owner of COOL WEB APP. Typical authentication with a web services involves the user providing specific credentials for your app like email and password. This information gets transmitted in a HTTP request and your backend verifies the credentials and grants access to user. Hopefully you also store the user credentials in an encrypted form. But there are many situations in which you may want to be the one in charge of creds. For example, you if wants any of your potential users to log in using their existing account with a different service (say, Google or Facebook), the user needs to authenticate with that third party service (that you trust). You are now delegating identity verification to a separate service. This is sort of the point of both SAML and OAuth at a high level, but they’re designed for different problems.
Implementing OAuth lets your users access your service through a trusted third party that does the auth. The user goes through a login flow with the third party and eventually the third party grants a token that your app can use to retrieve user information (such as email) that can be used to grant access to the COOL WEB APP. OAuth, however, is not designed for single sign on scenarios. That’s where SAML comes in. Implementing SAML for your web app is similar to OAuth in that you’re delegating the auth to a third party, but in this case that third party is a specific entity known as an “Identity Provider”. The identity providers job is to grant a user access to MULTIPLE cool web apps, not just yours. That’s basically single sign on in a nutshell. The user signs into a single service (the identity provider) and that service has a trust relationship with N services. The user can then log into N services (one of which is yours) all mediated through SAML.