11

私は API を構築しており、多くのコンテキストで認証を理解しようとしています。

セッションとパスワード認証

API は、作成およびデプロイするクライアント側アプリケーションを提供し、パスワードを使用して認証済みの要求を処理する必要があります。すべてのリクエストでパスワードを送信するのは得策ではないため、最初にログイン エンドポイントにアクセスしてセッション ID を取得する方が理にかなっています。問題の webapp は AngularJS で記述されており、localStorage で独自のセッションを追跡して、セッションのハイジャックを軽減し、セッションを追跡するための Cookie への依存を削除する必要があります。

webapp はすべてのリクエストでセッション識別子を送信する必要があり、現在はリクエストの本文で送信しています。これは非常に簡単に断片化され、API と密接に結合されます。リクエストの本文、URL、およびヘッダーにまたがるさまざまなフィールドではなく、すべての認証情報を 1 つの方法で (できればヘッダーを介して) 渡すことをお勧めします。

セッション ストレージ

もちろん、 Redisは素晴らしいです。セッション ストレージは簡単で、自動的にガベージ コレクションを行います。残念ながら、redis のセッションは管理が難しく、特定のユーザーのすべてのセッションを簡単に取り消すことはできません。グローバルキースペースの代わりに真の redis-datastructure にセッションを保存することでその機能を追加すると、キー付き TTL を追加する機能が削除されます。私の現在の解決策は、MongoDB ユーザー コレクションにセッションのリストを保存し、セッション アクティビティ (ログイン/ログアウトなど) で期限切れのセッションをガベージ コレクションすることです。

セッションはconnect-redisモジュールを使用して redis に保存されますが、リクエストごとに送信されるため、Cookie には含まれません。req.cookies現時点では、セッション識別子をリクエスト本文から取り出してオブジェクトに入れる小さなミドルウェアがあります。

var express = require('express');
var RedisStore = require('connect-redis')(require('connect'));

var app = express();
app.use(function(req, res, next) {
  req.cookies = {session: req.body.session};
});
app.use(express.session({
  store: new RedisStore({
    client: redisClient,
    prefix: 'session:'
  }),
  key: 'session',
  secret: 'all mine'
});

このアプローチは問題なく機能express.sessionしますが、エクスプレスが応答したときに最終的に Cookie を設定することになり、それは望ましい動作ではありません。

Express のコンテキストでこれを適切に設定するにはどうすればよいですか?

API キー

当社の API は、サードパーティ アプリケーションが当社のシステムへの限定的かつ制御されたアクセスを取得するための API キーもサポートする必要があります。これを行うために私が知っている最も一般的なメカニズムは、関心のある開発者に API キーを配布し、開発者に API キーを要求の一部として渡すことです。これは、セッション/パスワード認証が陥るのと同じジレンマに陥ります。すべての API は、ボディから URL、ヘッダーまで、リクエストのさまざまな部分で API キーを期待します。

拡張とオープン スタンダード

初期リリースでは OpenAuth や OpenID などのオープン認証標準をサポートする予定はありませんが、これらの標準を簡単に追加できるフレームワークを作成したいと考えています。その一部は、セッション/パスワードおよび API キーに基づく認証と同様に、認証資格情報が API に渡される方法を統一することです。

もう 1 つの質問は、HTTPAuthorizationヘッダーをカスタマイズするのが良い考えなのか、それともカスタム ヘッダーの方が良い考えなのかということです。

CRUD サポート

RESTful API の CRUD パラダイムをサポートするには、すべての API リクエストを POST リクエストに制限するため、ボディに認証情報を提供しないことが理にかなっていますが、CRUD ではさまざまな HTTP メソッドの使用が推奨されています。

TLDR

2つのこと：

  1. Cookie ベースのセッションを使用せずにconnect-redis のようなモジュールを使用するにはどうすればよいでしょうか。
  2. 最大限の柔軟性と相互運用性を実現するには、認証情報をどのように構成する必要がありますか?
4

2 に答える 2

2

You can consider not using sessions at all by having a token based approach.

You can generate an encrypted token with a hash containing at least user id and expiration date and server secret. You don't even need to include password once you verify the user on login request.

The token would be passed around in the Authorization header, avoiding the use of cookies or any other request parameter.

With this token you can identify the user and check the expiration date without needing a store on serverside, so no session state. You would only need a store if you need to expire authenticated tokens on demand.

于 2014-01-09T14:40:32.583 に答える