Доверяющие стороны OpenID должны иметь возможность убедиться, что полученное пользователем подтверждение действительно от поставщика OpenID.В противном случае ваш RP широко открыт для простых атак.
Традиционно проверка подписи требует, чтобы RP-сервер напрямую связывался с OP-сервером.Поскольку в вашем случае это невозможно, единственной альтернативой является жесткое кодирование общего секрета связи между RP и OP.Вы создаете дескриптор ассоциации и криптографически надежный секрет для этой ассоциации, и сообщаете об этом RP и OP и о том, что она никогда не истекает.Затем каждый запрос на аутентификацию, отправляемый вашим RP, должен запрашивать у OP использование этого конкретного дескриптора ассоциации.
Конечно, ассоциация, срок действия которой никогда не истекает, несет собственные риски безопасности.Вы можете уменьшить это (частично), убедившись, что это ассоциация HMAC-SHA256, а не просто HMAC-SHA1.
Наконец, для обнаружения идентификатора пользователя обычно требуется прямое HTTP-соединение от RP к OP, но это может быть легкоизбежать использования делегирования идентификаторов (установите идентификаторы на сервере без брандмауэра, который указывает на OP за брандмауэром).В качестве альтернативы, ваше решение для результатов обнаружения с жестким кодированием, включая OP Endpoint, тоже подойдет для специализированного решения.Вы должны быть осторожны, чтобы заблокировать все угрозы безопасности, которые это открывает (например, удостовериться, что идентификатор действительно из набора URL, который вы жестко кодируете, иначе люди могут подделать идентификаторы из других конечных точек OP.
Поскольку вы используете DotNetOpenAuth, вы можете создать собственный класс IDirectWebRequestHandler и установить его в свойстве OpenIdRelyingParty.Channel.WebRequestHandler. Этот обработчик будет иметь возможность перехватывать исходящие HTTP-запросы к [server-behind-брандмауэр] и «перенаправить» запрос, просто синтезируя свой собственный HTTP-ответ, то есть XRDS, который сервер за брандмауэром выдаст, если вы только сможете достичь его. Для каждого OP должно быть только два документа XRDS (один - OPИдентификатор, а другой - все заявленные идентификаторы, которые утверждает OP). Это должно обеспечить правильную работу вашего обнаружения как до, так и после аутентификации.