Я работаю над мобильным приложением, которое использует api, построенную с ASP.NET web api framework. Мы решили использовать ACS вместе с Custm STS в качестве механизма для защиты api. Мы используем пользовательскую STS, потому что нам нужно аутентифицировать пользователей против нашего собственного хранилища личных данных.Слабость в oAuth 2.0 - каковы альтернативы?
Информационный поток выглядит следующим образом:
- Мобильное приложение требует пользовательских STS с учетными данными пользователя.
- Пользователь аутентифицирован против нашего собственного хранилища личных данных.
- После аутентификации пользователя код авторизации извлекается из ACS и используется для получения токена доступа SWT.
- Токен возвращается в мобильное приложение.
- Мобильное приложение внедряет токен доступа в заголовок авторизации и отправляет запрос на API
- HTTP-модуль в API проверяет токен доступа, а данные возвращаются, если токен действителен.
Все делается через SSL, поскольку мы используем oAuth 2.0.
Проблема с oAUth 2.0 заключается в том, что она подвержена риску от атаки «человек в середине», поскольку токен SWT, выданный ACS, является сырым токеном и не зашифрован каким-либо образом. Тем не менее, он подписан с использованием 256-битного симметричного ключа.
Мы используем токены swt, потому что мы используем подход на основе http, а токен прекрасно вписывается в заголовок заголовка HTTP-запроса.
Microsoft представили некоторые рекомендации по безопасности ACS в следующем сообщении: http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx
мы в настоящее время реализовать 2 из них, как мы проверяем эмитент и аудиторию, то есть, что маркер был выдан нашим доверенным эмитентом (ACS) и что токен был выпущен для правильной аудитории (наш api).
наш сценарий основан на следующей статье: http://msdn.microsoft.com/en-us/library/hh446531.aspx как таковой WIF не используется для обработки входящих токенов. WIF используется только при обработке претензий.
Учитывая вышеупомянутый сценарий, есть ли что-нибудь еще, что мы могли бы сделать, чтобы улучшить реализацию, которую мы должны обеспечить для нашего отдыха на основе api?
любые комментарии/критика/предложения приветствуются.
спасибо.
SSL смягчает риск попадания людей в средние атаки. Без этого есть определенно открытая дверь для такого рода нападений, которые произойдут в вашем приложении. –