ユースケースの違い
OAuth
主にモバイルアプリやWebアプリで使われ、ユーザーが第三者アプリケーションに対して自分のデータへのアクセス権を付与するために使用されます。例えば、ユーザーがSNSアカウントを使って別のサービスにログインしたり、SNS上のデータにアプリがアクセスする権限を付与したりする場合に使われます。
SAML
主にシングルサインオン（SSO）に利用され、企業や大規模な組織のWebアプリ間での認証に適しています。例えば、企業のポータルサイトから社内の様々なアプリに一度のサインインでアクセスできるようにする場合に使われます。
認証VS認可
OAuth
認可プロトコルです。OAuthは「認可（Authorization）」にフォーカスしており、クライアントアプリケーションにリソースへのアクセス権を与えるために使用されます。認証機能自体は含んでいませんが、OAuth 2.0の上にOpenID Connect（OIDC）を使用することで認証機能を実装することが可能です。
SAML
認証プロトコルです。SAMLは「認証（Authentication）」にフォーカスしており、ユーザーが一度サインインすることで複数のアプリケーションにアクセスできるシングルサインオン（SSO）の仕組みを提供します。
トークン形式の違い
OAuth
アクセストークンとしてJSON Web Token（JWT）などのフォーマットを使用します。JSON形式であるため軽量で、モバイルアプリやAPI通信に適しています。
SAML
XML形式のSAMLアサーションを使用します。XMLベースのため情報量が多く、一般的にWebブラウザ間の通信やWebアプリケーションで使用されます。
使用される環境
OAuth
Webやモバイルアプリケーションなど、インターネットを介した様々な環境に適しています。APIの認可にもよく使用されます。
SAML
企業や組織内のWebアプリケーションのシングルサインオン環境に適しています。企業のイントラネットやB2B（企業間）環境で使われることが多いです。
アーキテクチャの違い
OAuth
OAuthの認証フローでは、リソースオーナー（ユーザー）、リソースサーバー、クライアント、認可サーバーといった役割が登場します。リソースオーナーがクライアントアプリにアクセス権を付与するという仕組みです。
SAML
SAMLのアーキテクチャでは、IdP（Identity Provider：アイデンティティプロバイダ）とSP（Service Provider：サービスプロバイダ）が主な役割を担います。IdPがユーザーを認証し、SPが提供する各サービスに対して認証情報を渡すという仕組みです。
参考サイト