OAuthは常に正しい選択です（そうでない場合））
ユーザーごとにAPIと対話する必要があるモバイルアプリケーションを作成しています。サードパーティのAPIのクライアントとしていくつかのプロジェクトに携わってきたため、私の最初の考えはOAuthを使用することでした。しかし、私はそれについて考えていて、APIを他の消費者に公開する予定はありません。唯一の消費者は常に私のモバイルアプリだけなので、OAuth実際に最適ですか？それともやりすぎですか？
次に この記事 Googleからのプロセスについてのアドバイスを読みます。これは、まさにこのシナリオに対する次のアプローチを示唆しています。
- 通常のWebベースのログインフォームを使用して、アプリにWebViewを埋め込みます
- ログインに成功したら、安全なトークンを持っているモバイルアプリに安全なクッキーを渡します
- 今後のAPIリクエストでトークンを使用する
（httpsなどすべてを想定）
これは他のどのOAuth実装よりもはるかに単純であるように見え、Spring Security Filter/authentication chain（私のサーバー側コードはJava＆Spring MVC/Secutiryなど）。興味深いのは、Googleが推奨するアプローチであり、これにより、ソリューションにある程度の信頼性が加わったと思います。
上記のソリューションでモバイルアプリキーなども含めたと仮定すると（フォーム/ APIにぶつかるモバイルを停止するためだけ）、OAuthと同じ問題が発生するようですモバイルコードに埋め込まれたアプリキーを含める必要があります（逆コンパイルできるなど）。
また、Amazonのアプローチについて この記事 を読みます（明らかにOAuth 1の実装）に似ています）。これは、上記のGoogleが提案するソリューションの合理的な拡張であると思われますトークンをサーバーに送信するのではなく、トークンをキーとして使用してリクエストデータをハッシュします。
私は、通常のWebベースのユーザー/パスワードセキュリティを超えたセキュリティで何かを実装するのはかなり新しいです。モバイルアプリでOAuthをいつ使用するか、および上記の2つのソリューション（Amazonおよびgoogle） OAuth 2。
質問の最初の部分への答えは簡単です。どのプロトコルもalwaysが正しい選択ではありません。
OAuthは、クライアントの認証や、ブラウザー、アクティブなクライアント、およびその間のあらゆるものにわたる細かい方法でのリソースの保護など、多くの小さな問題を解決します（解決策を提供します）。
これはやり過ぎになる可能性があるため、使用しないことをお勧めします。これは認証を行わず（OpenID ConnectはOAuthのauthn拡張機能です）、他のプロトコルが行うような特定の動作を提供しません。 SAMLですが、一方で、それは良いことかもしれません。
Googleが提供するソリューションには、OAuthの多くの特性がありますが、Cookieに大きく依存しており、一般向けに拡張できるようには見えません。 APIを公開する必要がない場合は問題ないかもしれませんが、必要な場合はOAuthがそのソリューションよりも優れたアプローチになります。
OAuthルートを使用する場合、OpenID Connectへのアクセスを提供する最新バージョンをサポートする必要があります。そうしないと、独自の認証手段を構築するのが困難になります。クライアントはカスタム設計に対して実装する必要があります。