Редактировать :
Прошло несколько лет с тех пор, как я впервые написал ответ, и список стареет. Широкое распространение получили веб-интерфейсы API и ретрансляция доверия на основе токенов.
Я не читал его, но Безопасность Windows Communication Foundation было бы хорошим началом, если вы ищете что-то конкретное для WCF.
Также следите за тем, что делают крупные игроки, такие как Facebook , Google и Twitter . Они используют открытые протоколы, такие как OpenID и OAuth . Сначала OAuth выглядит сложным, но вы должны понимать механизм.
По моему мнению, ранее OAuth заново изобретает множество колес, которые SSL уже решил, и оставляет некоторые дыры в безопасности открытыми. Интересное чтение - Компрометирующая система безопасности OAuth в Twitter . Реализация Facebook OAuth 2.0 и Реализация Google OAuth 2.0 упрощает многие из этих проблем, используя https там, где это имеет смысл. Это должны читать.
Основная концепция OAuth - ретрансляция доверия. Вы бы хотели, чтобы сторонние разработчики создавали приложения для вашего API, но конечные пользователи не всегда могут доверять этим приложениям. Дать им пароль - все равно что дать ключи от королевства. Таким образом, пользователь вводит пароль в ваш пользовательский интерфейс, а ваш пользовательский интерфейс перенаправляет третьему лицу с токеном доступа.
Создание безопасных приложений ASP.NET: аутентификация, авторизация и безопасная связь - хорошее введение в модели безопасности ASP.NET. Вы можете пропустить детали, потому что большая часть технологии устарела.
Хорошим обзором, специфичным для веб-служб, является Безопасность веб-служб: сценарии, шаблоны и руководство по внедрению для расширений веб-служб (WSE) 3.0 . Это говорит WSE, но основные понятия все еще остаются теми же.
Для получения более подробной информации о WS-Security прочитайте Защита веб-служб с помощью WS-Security: демистификация WS-Security, WS-Policy, SAML, подписи XML и шифрования XML .
После прочтения выше, что действительно помогло мне, так это посмотреть на существующие реализации, такие как Аутентификация Amazon S3 :
Аутентификация Amazon S3 http://docs.amazonwebservices.com/AmazonS3/2006-03-01/images/HMACAuthProcess_You.gif
API аутентификации Flickr :
Каждая аутентификация специфична
пользователю и API приложения
ключ, и может использоваться только с этим
ключ.
Ложки аутентификации действительны в течение 60
минут с момента его создания,
или пока приложение не вызовет
flickr.auth.getToken, в зависимости от того, что
рано.
Только одна аутентификация
заявка на пользователя будет действительна при
в любое время. Заявки должны иметь дело
с истекшим и недействительным
аутентификация лягушек и знать, как
обнови их.
API Twitter REST
Многие методы API Twitter требуют
аутентификация. Все ответы
относительно контекста
аутентифицирующий пользователь. Например,
попытаться получить информацию о
защищенный пользователь, который не дружит с
запрашивающий пользователь потерпит неудачу.
Для
в настоящее время HTTP Basic
Аутентификация является единственной поддерживаемой
схема аутентификации. когда
проверка подлинности через Basic Auth, используйте
ваше зарегистрированное имя пользователя или адрес электронной почты
адрес в качестве компонента имени пользователя.
Сеансовые куки и параметрические
логин, как известно, работает, но не
официально поддерживается.
OAuth
схема аутентификации на основе токенов
в ближайшее время будет предложен в качестве экспериментального
бета-версия.
Так что приятно знать сложные сертификаты и PKI, но мир, кажется, работает без него просто отлично.