認証の方法としてよくパターンは、ユーザがアプリに「ユーザ名」と「パスワード」を入力し、アプリがサービス（Web APIなど）にユーザ名とパスワードをそのまま送信するパターンです。 このパターンは以下のメリットとデメリットが存在します。

• メリット :
  • 実装者視点でアプリとサービスの連携が簡単になる。
• デメリット :
  • 利用者視点でアプリにパスワードを共有するため、信頼できるアプリか検証する必要がある。

例えばLDAP認証をする際、アプリはユーザが入力した「ユーザ名」と「パスワード」をそのままLDAPサーバに送信することで、有効なクレデンシャルかどうかは判断します。 これはある意味、中間者攻撃（Man-In-The-Middle Attack; MITM）になるのですが、多くのユーザはこのアプリ（中間者）が悪意のないものとして、アプリとクレデンシャルを共有しています。 しかし、もしアプリが悪意のあるもので、入力した「パスワード」を外部の別サーバに送信していたら大問題です。 また、サービスは認証が必要なアクセスが、正規ユーザからなのかアプリからなのか区別できない問題もあります。

アプリとサービスで情報を共有するためだけの「特別なパスワード」を発行して使う方法もありますが、クレデンシャルの生成・配布・管理に手間がかかるため、この方法は広く受け入れられていません。

この問題を解決するためのプロトコルがOAuthです。 OAuthは、制限されたクレデンシャルを発行し、それをサービス利用時に使えるような仕組みを提供するプロトコルです。