Проектування автентифікації для REST API

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

Я придумую це на основі таких фактів щодо стека додатків:

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

З 3-го року я хотів використати форму аутентифікації лексеми, так що після того, як сервер підтверджує облікові дані, клієнт отримує токен для використання в решті програми (це дозволить мені робити інші речі, наприклад, витримка користувачів, можливість безперебійного переміщення користувачів між веб-та настільними версіями тощо). Зрозумівши, як зробити дзвінки повторними та несанкціонованими, я придумав таке:

1. Перш ніж клієнт намагається пройти автентифікацію, він генерує пару ключів Diffie-Hellman, використовуючи 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). АСУ коштує грошей, але це дуже дешево (10 000 транзакцій за 0,01 долара) і велика кількість інфраструктури обробляється. WIF використовується на клієнта.

Це також рішення, що ґрунтується на стандартах / претензіях - і це все, що викликає гнів. Перегляньте цю статтю про спільне використання WCF та REST та ACS разом .

Якщо ви думаєте про майбутнє, це також механізм, який може розвиватися разом з вами - як у вас є мобільні додатки поза брандмауером, партнерами тощо. Навіть якщо ви не хочете використовувати його, оскільки він додає залежність поза вашим брандмауером, ви можете перевірити його на ідеї. Дуже струнка.

Удачі! -Зарахунок