バンキング モバイル HTML5 アプリケーションの可能性を探っています。RESTful API を介してメイン サーバーと通信します。モバイル アプリで OAuth を使用して API にアクセスしているという話をよく耳にします。たとえば、SpringSource のhtml5expenseデモ アプリ。
だから、なぜわざわざするのか完全には理解できませんか？ユーザーは標準的な方法でログインし、アプリが REST にリクエストを行うときにユーザーを識別するために使用されるセッション ID (または Play フレームワークの場合はセッション データ) を含む Cookie を受け取ることができませんでしたか?
通常、Oauth はほとんどの BASIC AUTH、つまり「標準的な方法でログインする」アプローチよりもはるかに安全です (そして、OAuth はますます標準になりつつあります)。
ログインすると、ほとんどの「標準的な」方法で、ユーザーは自分のユーザー名とパスワードをアプリケーションに入力します。ユーザー名とパスワードは、多くの場合、ローカルに保存されるか、アプリケーションに転送され、「メイン サーバー」に中継される可能性があります。たとえば、API を提供します。そのため、ユーザーは非常に秘密のログイン情報 (バンキングなど) を、知らない、または信頼していないクライアント、アプリ、またはシステムに入力する必要があります...
OAuth を使用すると、ユーザーはその API の所有者のログイン ページに誘導されます。たとえば、銀行などです。ユーザーは、知っている安全なログイン ページにログインし、アプリケーション「xyz」が必要とすることに同意するよう求められます。彼のデータにアクセスするには....そのアクセスを要求したアプリケーションには、ユーザー名とパスワードを知らなくても API にアクセスできるトークンが与えられます。そうすれば、ユーザーが信頼する場所で、ユーザー名/パスワードを一度だけ入力できます。
さらに、ユーザーは後でログインしてページ .. (銀行アプリまたは管理者フロントエンド) を許可し、API へのアクセス権を削除して、パスワードを変更することなく、アプリケーションが自分の情報にアクセスするのを停止できます。
実際に安全であるという効果を超えて、銀行アプリに OAuth のようなものを使用することも理にかなっています。最新のセキュリティ技術が適用されれば、人々はより自信を持つことができるからです。安心感も増します。
APIをサードパーティの開発者に公開しない場合。OAuthを気にする理由は本当にありません。
OAuthが存在する最大の理由は、ユーザーがユーザー名とパスワードをサードパーティに提供することなく、APIとの統合を可能にすることです。その他の理由は、リソースへのサードパーティのアクセス、またはスコープアクセスに時間枠を設定できることです。