Разработка аутентификации для REST API

Я работаю над API для службы REST, которую собираюсь и производить, и потреблять. Я провел последние несколько дней, пытаясь понять, как правильно обращаться с аутентификацией, и думаю, что наконец-то что-то придумал.

Я придумаю это на основе следующих фактов о стеке приложений:

1. Клиент и сервер находятся в .NET4 (часть клиента в профиле клиента)
2. Сервер выставляется с использованием WCF REST
3. Я действительно не хочу хранить имя пользователя и пароль в памяти приложения

С 3 я хотел использовать форму аутентификации токена, чтобы после проверки учетных данных сервером клиент получал токен для использования в остальной части приложения (это позволит мне делать другие вещи, такие как время ожидания пользователей, возможность плавного перемещения пользователей между веб-версиями и версиями для настольных компьютеров и т. д.). После того, как я выяснил, как сделать вызовы воспроизводимыми и защищенными от несанкционированного доступа, я придумал следующее:

1. Прежде чем клиент попытается аутентифицироваться, он генерирует пару ключей Диффи-Хеллмана, используя ECDiffieHellmanCngкласс.
2. Он передает открытую часть пары ключей по проводам вместе с именем пользователя и паролем (конечно, через HTTPS).
3. Сервер аутентифицирует комбинацию имени пользователя и пароля, в случае успеха он затем делает следующее:
   1. Создает уникальный токен сеанса
   2. Генерирует свою собственную пару ключей DH и вычисляет общий секрет из открытого ключа, предоставленного клиентом
   3. Запоминает токен сеанса, общий секрет, пользователя и время «последнего действия» (используется для скользящего окна истечения) в своей базе данных
   4. Возвращает маркер сеанса, его открытый ключ DH и сообщение об успешной аутентификации
4. Клиент берет ключ DH из ответа, вычисляет общий секрет и сохраняет токен и секрет в памяти.

С этого момента комбинация токен / секрет сеанса работает, как и большинство других API REST, с запросом, который снимают и ставят метки времени, а затем генерируют HMAC. Всякий раз, когда клиент выполняет действие против сервера, он проверяет пару токен / секрет и разрешает действие, если оно допустимо и не истекло, и обновляет последнюю запись действия в сеансе.

Я не вижу никаких явных недостатков, и, вероятно, слишком перегружен для этого, но мне нужно научиться делать это в какой-то момент. HMAC предотвращает повторные атаки, согласование DH помогает предотвратить MITM-атаки (я не могу представить себе работоспособную атаку на макушку между HMAC / DH).

Любые дыры, которые кто-нибудь может проткнуть в этом?

Вместо того, чтобы придумывать свое собственное, вы должны рассмотреть возможность чтения API OpenAM и заимствовать его.

http://forgerock.com/openam.html

OpenAM Wiki особенно полезен

https://wikis.forgerock.org/confluence/display/openam/Home

Вам не нужно использовать их компоненты. Но если вы используете их API, вы обнаружите, что ваша жизнь будет проще в долгосрочной перспективе.

Я согласен на 100% с @ S.Lott, что ты не хочешь делать свои собственные. Я предлагаю рассмотреть другую альтернативу: Службу контроля доступа Windows Azure (ACS). ACS стоит денег, но он очень дешевый (10 000 транзакций за 0,01 доллара США) и обрабатывается большое количество инфраструктуры. WIF используется на клиенте.

Это также основанное на стандартах решение, основанное на претензиях, которое является модным. Проверьте эту статью об использовании WCF и REST и ACS вместе .

Если вы думаете о будущем, это также механизм, который может расти вместе с вами - поскольку у вас есть мобильные приложения вне брандмауэра, партнеры и так далее. Даже если вы не хотите использовать его, поскольку он добавляет зависимость вне вашего брандмауэра, вы можете проверить его на предмет идей. Очень гладко

Удачи! -Билл