2012-06-08 2 views
3

Я работаю над мобильным приложением, которое использует api, построенную с ASP.NET web api framework. Мы решили использовать ACS вместе с Custm STS в качестве механизма для защиты api. Мы используем пользовательскую STS, потому что нам нужно аутентифицировать пользователей против нашего собственного хранилища личных данных.Слабость в oAuth 2.0 - каковы альтернативы?

Информационный поток выглядит следующим образом:

  1. Мобильное приложение требует пользовательских STS с учетными данными пользователя.
  2. Пользователь аутентифицирован против нашего собственного хранилища личных данных.
  3. После аутентификации пользователя код авторизации извлекается из ACS и используется для получения токена доступа SWT.
  4. Токен возвращается в мобильное приложение.
  5. Мобильное приложение внедряет токен доступа в заголовок авторизации и отправляет запрос на API
  6. 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?

любые комментарии/критика/предложения приветствуются.

спасибо.

+0

SSL смягчает риск попадания людей в средние атаки. Без этого есть определенно открытая дверь для такого рода нападений, которые произойдут в вашем приложении. –

ответ

2

Я думаю, вы уже принимаете правильный подход. Самое главное - проверить, подписан ли токен ACS. Никогда не делитесь секретным ключом ACS с кем-либо еще. Если они не знают ключа, они не могут подделать подпись.

Также не храните конфиденциальную информацию в токене (например, пароль, номер кредитной карты и т. Д.). Вы должны ожидать, что токен может быть получен кем-то другим, но никто не может подделать токен с правильной подписью.

+0

большое спасибо.Кроме того, можете ли вы предоставить какие-либо материалы о ресурсах, если они есть, о реализации oauth 1.0 с ACS в .NET. – user1426145

+0

Существует несколько образцов ACS SDK, связанных с OAuth. Например: http://msdn.microsoft.com/en-us/library/windowsazure/gg185937. –