EDUARD SAPOTSKIНо собственно вопрос - к каким методам Вы пришли и что используете в своих проектах?
Мы используем федеративную аутентификацию.
Это добавляет сложностей с развертыванием, но дает и свои преимущества.
Все делается на базе WIF (сейчас это часть .Net Framework). Его же [WIF] средствами, мы проверяем и credentials клиента на сервисе токенов.

Что касается вашего вопроса, то я немного не уловил его суть - в чем именно состоит "костыльность" стандартных аутентификационных методов?

Собственно, базовый WCF предлагает ровно 4 типа credentials, которые вы можете передать с клиента:
- Windows . Передается некая крипто-функция на основе доменного аккаунта и пароля. Работает в рамках домена и для доменных пользователей (т.е. можно обращаться и извне, но пользователь все равно доменный).
- User/Password . Передается сам пароль. Требуется защищенный канал (хоть на уровне транспорта, хоть на уровне сообщений). Для проверки можно использовать или Windows Security (тогда это мало отличается от первого варианта), или ASP.Net Membership Provider о котором вы упомянули или Custom UserName/Password validator. Последний прост как 3 рубля - там 1 метод с именем и паролем и все...
- Certificate . Передается открытая часть сертификата + образец подписи, который подтверждает наличие у вас закрытого ключа (чуть сложнее, на самом деле, но суть примерно такая). Обычно такой метод используют для аутентификации сервис-сервис, но можно аутентифицировать и пользователей (тогда нужно просто иметь механизм сопоставления "сертификат - пользователь"). Я правда использовал этот вариант только для аутентификации сервисов, но помню, что есть готовый механизм маппинга сертификатов на Windows-аккаунты.
- Issued token . Собственно это и есть основа для федеративной аутентификации, когда вы у некоего сервиса получаете токен, а затем уже им пользуетесь для обращения ко всем остальным.

Вроде все достаточно просто и понятно.

EDUARD SAPOTSKIВ принципе меня все устраивает, уже несколько десятков приложений собрал по этой методе, все работает, никто ничего не взломал и не задосил.
Я не знаю, как именно вы генерируете Guid, надеюсь, вы не используете для этого стандартный Guid-генератор, (тот который Guid.NewGuid()). Ибо последний - вещь сугубо детерминированная и абсолютно неслучайная. Подобрать её не составит труда.

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

Ну а так, вы просто создали свою реализацию механизма сессий. Чем она лучше стандартных я не берусь судить. Может и лучше... Единственное, я бы все же доработал слегка этот механизм и передавал бы этот Id сессии неявно (хотя может у вас так и сделано, а сигнатуру с явным Guid вы привели просто для понимания идеи - тогда предложение снимается).

EDUARD SAPOTSKIМожете показать мастер-класс по подбору детерминированного гуида? А то шума в сети по этому поводу много, а подобрать желающих мало.
Да, вы правы - мои знания о природе GUID несколько устарели.
На текущий момент от инкрементального GUID Microsoft отказались и используют pseudo random реализацию. На сколько она устойчива к подбору, судить не берусь.