4

TL;DR - The Problemと記されたセクションはスキップしてください。

いくつかの背景

そこで私は、内部 API を裏返しにして開発者が使用できるようにすることについて、いくつかの質問への回答をネットで探しています。私たちの API はすでに運用されており、現在、必要に応じて標準セッションを使用して保護されています。

独自の API にドッグ フードを提供することは素晴らしいアイデアであると確信しているので、この部分は省略できます。私の質問は、内部を取り、外部であることを安全にすることと非常に関係があります.OAuth2を入力してください.

フロント エンドでは、サイトのいくつかのセクションにまたがる angular.js アプリです。1 ページのアプリではないことを強調することが重要だと思います。バックエンドには、django-rest-framework を使用して構築された残りの API を持つ django があります。バックエンドの詳細はそれほど重要ではないと思いますが、注目に値するのは、django がこれらのページの一部をレンダリングすることです。これは、場合によっては、Angular が API からすべてを要求するのではなく、事前にデータが渡されることを意味します。これは、サイトの特定のセクションをより SEO フレンドリーにするのにも役立ちます。ページがレンダリングされ、必要な初期データが angular に渡されると、すべてが angular.js --> api になります。

実際に質問の核心に入る前に言及する最後の詳細は、API が現在いくつかのパブリック エンドポイントを持っていることです。フロント エンドで公開されているコンテンツは定義上、API から公開されていますが、これはおそらく私たちが望んでいるものです。変更する。

いくつかの推論

私は OAuth2 仕様を最初から最後まで何度か読みました。オンラインで見つけたすべての記事を読みました。このテーマに関する本も購入しましたが、私にとって欠けている部分が 1 つだけあります。私は、Web プラットフォームの現在の認証を OAuth に置き換える実装を理解しました。

私たちの API をサードパーティが利用できるようにする場合、現時点では OAuth2 が唯一の適切な選択肢のように思えます。APIにドッグフードを与えることは、それを改善するだけです. そのため、Needing Access トークンが残ります。ここは判断がつかないところです。

メインの Django API (現在はフラスコで記述) から API を分離し始めているため、API に oauth を追加することは非常に自然なステップになるでしょう。アンギュラーキーを与えることは明らかにできないので、何が残るでしょうか?

問題

セッションベースの認証を OAuth2 に置き換えることはできますか? 内部 API は現在、セッションを使用して認証されています。サードパーティが API を利用できるようにした場合、メインの Web プラットフォームに OAuth をどのように実装できますか?

デフォルトでは HTTPS です

  • ユーザーがログインしたら (リソース所有者のパスワード フロー)、サイトの現在の機能を非常によく複製し、そのトークンを直接使用しても安全ですか。トークンは django で永続化でき、必要に応じて単純に angular js アプリケーションに渡すことができます。

  • django と API の間にある種のプロキシが必要でしょうか? これは http リクエストを 2 倍にしますが、ローカル ネットワークではそれほど悪くないのでしょうか?

  • 暗黙の許可フローを使用して、Angular で完全に処理できますか? ユーザーのトークンの有効期限が切れていることを理解しているように、ユーザーが認証サーバーにログインしたままである限り、angular は別のトークンを非同期的に要求して、

  • ユーザーが私たちのサイトにアクセスしたとき、OAuth フロー全体が透過的である必要があります。これにより、クライアントの資格情報が魅力的に見えましたか? このフローと機能する可能性のある API へのプロキシの組み合わせはありますか?

  • これは大物の誰かがすることですか?? フェイスブック、ツイッターなど？

正直なところ、上記のどれも優れたオプションのようには思えません。それは全面的にひどい影響を与えるでしょう。開発中にこれらのオプションを使用することがどれほど大きな苦痛になるか想像できません. つまり、これは良い考えですか？私が見落としたもっと簡単な方法はありますか？

仕様は常に、モバイル クライアントのようなファースト パーティのアプリを信頼している場合の解決策を示唆していますが、正直なところ、ファースト パーティが実際には Web サイトである場合について考えたことには、まったく刺激を受けませんでした。

時間をかけてこれを読んでくれた人に感謝します。私が述べたように、私はこれらのトピックで見つけることができるすべてを読みましたが、ほとんどは次のことに基づいています-独自のAPIを使用する必要がありますか、それともシングルサインオンをどのように使用できますか? 私が探しているのは、これらのことを実用的な意味で実際に実装するための情報であり、うまくいけば、生産でこれを達成した魂のための知恵の真珠です.

これを読んでくれてありがとう。

4

1 に答える 1

0

私はこれについてしばらく考えていました - 私は現在、ノードに組み込まれたREST APIにアクセスするAngularアプリケーションの構築に取り組んでいます。REST に合わせて、セッションを維持するべきではなく、代わりに、各要求と共にユーザー/パスワードの詳細を渡す必要があります。

明らかに、多くの API は何らかの基本的な認証または API キーに固執して oauth2 を回避できますが、私は google/facebook でログオンしたかったので、ある程度のトークン ラングリングが必要になりました。私が使用している特定のフローはこれです -

  1. ユーザーが angular アプリケーションにアクセスします。ログインしていないため、ログイン ページが表示され、google/facebook でログインすることを選択できます。

  2. 彼らがクリックしてGoogleでログオンすると仮定すると、リンクはリクエストをノードサーバーに送信し、ユーザーをGoogleサインインページにリダイレクトしてGoogle認証フローを開始します。

  3. それらはアプリ/ログインへのアクセスを提供し、ノード サーバーにリダイレクトして戻します。ノード サーバーは、Google から oauth2 トークンを取得します。その後、ノード サーバーは、特定のユーザーのこのトークンを格納します。

  4. 最後に、ノード サーバーはヘッダー内のトークンと共に angular アプリにリダイレクトします。このトークンはブラウザー セッションに保存され、アプリが API 要求を行うときに使用されます。API リクエストが有効なトークンを受け取った場合は、同じように応答します。それ以外の場合はエラーを渡し、angular アプリはこれを記録し、関連するエラー通知とともにログイン ページにリダイレクトします。

API をサード パーティに公開する場合は、おそらくもう少し作業を行う必要がありますが、現時点ではあまり考慮していません。

于 2013-10-08T10:22:20.580 に答える