インフラストラクチャに新しい REST ベースのAPIを実装したいと考えていますが、 OAuthが適しているようです。
私たちの実装では、最初にサーバー間アクセスのみがあり、これは完全に制限されません。これは二足認証と呼ばれるものだと思います。
後で、API をブラウザーで使用できるようにしたいと考えています。これにより、承認が 3 段階になります。
これを実装するための良い出発点はありますか? サーバーを完全に承認し、今後ユーザーごとに制限付きの承認を追加するにはどうすればよいでしょうか?
OAuth 仕様はこれらのシナリオではあまり役に立ちませんが、これは、サーバー間アクセス用に無期限のセッションを作成し、後でユーザーのみの API へのアクセスが制限された通常のセッションを追加する必要があることを意味していると思います。
詳細についての出発点を見つけたいと思っています。お知らせください。
OAuth は私に適していますか? 私は認証された要求システムのみを探しています。このシナリオでは、コンシューマーとサービス プロバイダーのみが存在します。エンドユーザーは遊びに来ません！
ええ、OAuth はおそらくあなたのためです。
実は OAuth 仕様には 3-legged バージョンと 2-legged バージョンの 2 つがあります。3本足のバージョンは最も注目を集めているバージョンであり、使用したいバージョンではありません.
良いニュースは、2-legged バージョンがまさにあなたが望むことを行うということです。これにより、アプリケーションは共有秘密鍵を介して別のアプリケーションにアクセスを許可できます (Amazon の Web サービス モデルと非常によく似ており、HMAC-SHA1 署名方法を使用します)。または公開/秘密鍵システム経由 (署名方法: RSA-SHA1 を使用)。悪いニュースは、まだ 3 脚バージョンほどサポートされていないことです。そのため、他の方法で現在必要な作業よりも少し多くの作業を行う必要がある場合があります。
基本的に、2-legged OAuth は、現在の日付、「ナンス」と呼ばれる乱数、およびリクエストのパラメーターを含む複数のフィールドに「署名」する (ハッシュを計算する) 方法を指定するだけです。これにより、Web サービスへのリクエストを偽装することが非常に難しくなります。
OAuth はゆっくりと、しかし確実にこの種の標準として受け入れられるようになりつつあります。長期的には、OAuth を採用することで、さまざまなライブラリを利用できるようになるため、最良の結果が得られるでしょう。
あなたが最初に知りたいと思うよりも複雑ですが、良いニュースは、多くの人がそれに多くの時間を費やしているので、何も忘れていないことを知っているということです. 好例は、ごく最近、Twitter が OAuth セキュリティのギャップを発見したことです。コミュニティは現在、そのギャップを埋める作業を行っています。独自のシステムを発明した場合、これらすべてを自分で把握する必要があります。
幸運を！
認証と承認を区別することを忘れないでください。いくつかの場所では、OP が 2 つを混ぜ合わせていると思います。
たとえば、サーバーが誰かを認証すると、通常、サーバーは明示的または暗黙的に (Cookie を使用して) 認証トークンを提供し、後続の要求が既に承認されているようにします。
資格情報の存続期間はサーバー次第です。資格情報がある時点でタイムアウトになるように計画することは賢明です。クライアントサーバーが「認証期限切れ」エラー応答を受信するたびに再認証できるように準備してください。
次の理由から、「無期限」のセッションを提供しようとはしません。
すべてのものはある時点で期限切れになります。たとえば、電源が失われたり再起動されたりした場合、クライアント サーバーはどのようにしてアプリケーションへのアクセスを再開できるのでしょうか?
柔軟性のないシステムを作成しています。彼らはより頻繁に壊れる傾向があります。
OAuth は、私たちのニーズには難しすぎるでしょう。Amazon S3 の認証スキームを採用することに決めました。これは、単に私たちのモデルにより適しているからです。
答えを見つけるのを手伝ってくれてありがとう..