サードパーティのAPIアクセス：OAuthは本当に必要ですか？
REST API（たとえば、our-app.com）を使用するWebアプリケーションがある場合、サードパーティのWebアプリケーションにAPIを開きたい（たとえば、their-app.com）。OAuth、OpenID Connectなどについて読んだ後、これらが私たちの意図した用途に本当に必要かどうか疑問に思います。以下は、既存のセッションベースのログインメカニズムを拡張して、同様に機能します。
より正確には、次のことを実現したいと考えています。
- ユーザーは、Webアプリケーションour-app.comのアカウントを持ち、ログインしています。
- ユーザーが（同じブラウザで）their-app.comにアクセスします。
- ユーザーは、自分のデータをtheir-app.comと共有することに同意します。
- これで、their-app.comは、認証されたクロスオリジンAJAX APIリクエストをour-app.comに送信できます。ブラウザは既存のセッションCookieを送信するので、ユーザーが既にサイトにログインしている場合は、別途ログインする必要はありません。
提案された実装を確認して、セキュリティ上の欠陥やその他の欠点を指摘していただけますか？使用するとどのようなメリットがありますか。 OAuth代わりに？
- Their-app.comは、APIを使用するために登録します。その結果、「their-app.com」が許可されたCORS Originとしてデータベースに追加されます。
- ユーザーが自分のブラウザでtheir-app.comにアクセスします。
- TheirAppリクエスト https://our-app.com/me ユーザーがログインしているかどうかを確認します。
- 技術的には、これは「withCredentials」AJAXリクエストです。
- Their-app.comは登録済みのOriginであるため、このクロスオリジンAPI呼び出しはWebサーバーで許可されています。 （不明なOriginのanother-app.comからのすべてのCORSリクエストは拒否されます。）
- ユーザーがログインしていない場合、またはユーザーはログインしているが、your-app.comへのアクセスをまだ許可していない場合、応答にはURLが含まれます。このURLはログインページを指します（たとえば、 https://our-app.com/login?origin=their-app.com ）。その後、TheirAppはこのリンクを新しいタブで開き、ユーザーがログインできるようにします。
- ログインページでユーザー名/パスワード（まだログインしていない場合）が要求され、セッションCookieが設定されて、「your-app.comがデータにアクセスすることを許可しますか？」これはすべて別のタブで行われるため、パスワードはtheir-appによって監視されません。
- ユーザーがアクセスを許可すると、ユーザーの決定を記憶するためのエントリ（「their-app.com」、userID）がデータベースに追加されます。
- APIへのクロスオリジンリクエストはすべて次のように処理されます：
- まず、Originが登録されているかどうかを調べます。そうでない場合は、拒否してください。
- 次に、セッションCookieが提供されている場合は、ユーザーのセッションを調べます。
- ユーザーがログインしていて、Originへのアクセスをまだ許可していない場合は、リクエストを拒否し、上記のようにリンクを返します。
- ユーザーがログインしていて、サードパーティへのアクセスをすでに許可している場合は、独自のWebアプリからの同じ元のリクエストと同じ方法でリクエストを処理します。
- ログインしていない場合は、公開データのみにアクセスできます。
それはすべて古い格言に帰着します：「優れたITセキュリティはhard "です。
ここでは、致命的である既知の懸念はありませんが（ビジネス全体およびクライアントモデル全体を知ることはできません）、深刻な疑問を投げかけますまたは少なくとも本当に真剣に考えるべきことであり、地味に取る価値があります。
それをひっくり返して、ユーザーの視点を見てください。ユーザー/顧客に、API（ユースケース：1つのサプライヤ）と標準化された既知のAPI（ユースケース：多く）の学習と活用に時間/お金/リソースを投資するよう求めています。活動を停止すると、彼らの努力は無駄になります。自分の作業を再利用したい場合は、最初にそのパスを採用しないことで回避できる追加の禁止作業がなければ、簡単に転送または再適用することはできません。オープンスタンダードがオープンである理由があります-それらがすべての人に合うわけではないかもしれませんが、それらは広い視野で他の利点を持っています。
彼らはまた、ユーザーとしてのこのコンセプトの長期的なメリットを自分たちがいかに確信しているかに懸念を抱くでしょう。彼らはあなたのビジネスの持続性、あなたのアプローチ、このパスへのあなたのコミットメント、そしてこのパスへのあなたのコミットメントへの彼らのコミットメントを考慮して評価するかもしれません、そして彼らはあなたとその製品とそれらの使用がどれほど確かであるかを評価します製品はすべて今後数年のうちにまだ存在します（多くはそうではありません）。相互運用性についてはどうですか？ otherサプライヤが、より小規模で独自のAPIを含めるか、他の機能として販売できる有名なAPIを含めるかどうかが問題になる可能性があります。それらのユーザー、またはそれぞれに「シム」を書く必要なしにデータを他のパッケージに取り出すことができるかどうか。彼らはメンテナンスの負担やこれが引き起こすかもしれない疑問を望んでいるのでしょうか？
第三に、人々がそれを熱望している場合でも、これも考慮してください：あなたのアプローチが既存のバージョンよりも安全に実装されていると信じる根拠は何ですか？ ？これは「より安全に設計された」とは異なります。自家製のセットアップははるかによく適応され、ニーズに適しているかもしれませんが、両方の設計とその設計の実装を開発する能力とスキルを持っていると確信していますか、それはITSecの現実の世界に耐えますか？できると思ったとしても、それを利用しようとする信頼のある第三者は完全に同意しますか？
第4に、独自の開発者向けのフレームワークは、それに影響を与えるセキュリティの世界の変化、またはポジティブな面では、新たな新しい標準/開発に迅速かつ確実に対応できる可能性があることを考慮してください。生産されたら、継続的に最新の状態に保つことに重点を置くことを約束するために、ビジネスにリソースがありますか？ （あなたは、あなたがビジネスを説明していないかもしれません）。予想よりも大きなリソースの流出を計画します。
あなたの質問の言い回しは伝えています、そしてあなたが必要とする最後の部分であるべきです：
私たちが意図した使用のためにこれらが本当に必要かどうかは疑わしいです<<。 >>より単純な実装...でもうまくいくと思います<<
つまり、不要な機能やコンピテンシーが追加されている可能性があることを除いて、実際にはマイナス面があるとは思わないでしょう。しかし、それでも、パッケージのすべてが必要でなくても、パッケージを使用する価値があるかもしれません。そうすることには、他にも多くの利点があるためです。結局のところ、any主要なソフトウェア（素朴なMS WordからApache Webサーバーまでの簡単な例です）の「ほとんどの」機能を使用している人はほとんどいません。すべての機能が使用されるわけではありません。
ビジネスとしてのあなたの目標は、自信（あなた+クライアント）、スピード、コスト/時間の効率に基づいているでしょう。セキュリティの必要性を検討しているほとんどの企業にとって、既成のソリューションは、今日必要とする以上のものであっても、すべての主要な面で自家製の独自仕様を日常的に打ち負かす可能性があります。
私はあなたが書いたすべての詳細を読んだのではなく、一般的な観察をしたいだけです：あなたは既存の標準のre-implementingの一部を計画しています。ほとんどの場合、数か月後には別の機能が必要であることに気づき、その標準をさらに再実装する必要があります。専門のレビュアーチームを持つ天才の暗号技術者でない限り、設計または実装のいずれかで、途中で（または多くの）間違いを犯す可能性が高くなります。
さらに、すべてのサードパーティに、サイトに固有の新しいことを学ぶように強いています。つまり、OAuth=を統合する方法をすでに知っているサードパーティは、彼らの知識から何の利益も得ず、仕事を終わらせるだけでなく、スキームの学習に多くの時間を費やす必要があります。 わからないすでに知っているOAuth彼らは今すぐにそれを学び、その知識を次回再利用できるという利点を得られません。いずれにせよ、サードパーティクールな新機能を開発する代わりに、独自の認証方法を学ぶのに時間を費やす必要があります。それで、統合を容易にした競合他社の何かのために何かを開発する代わりに、なぜあなたに役立つ何かを開発する必要があるのですか？
NIHは陥る悪いトラップです。すでにあるものを使うだけです。
すでに与えられているよりビジネス指向の回答に加えて、OAuthを使用することには技術的なメリットもあると思います。
サードパーティアプリ（OAuthクライアント）がOAuthアクセストークンを取得すると、ブラウザから両方のリクエストを作成するために使用できます（例：AJAX requests ）、バックエンドから（これが間違っている場合は修正してください...）
私が提案したカスタムソリューションでは、ブラウザーからのリクエストのみが可能です。サードパーティアプリはアクセストークンを取得することはなく、WebサイトのセッションCookieを暗黙的に使用します。開発者を特定のアーキテクチャに強制するため、これによりAPIの能力が低下します。ブラウザは、私たちとそのバックエンドの間でデータを渡すための「プロキシ」として常に必要です。