Межсерверный кроссплатформенный доверенный обмен

Похоже на OAuth2. Авторизация и предоставление API для каких-то операций с данными сервера.

Реализовать не сложно, но, вдруг, есть уже готовое и станартное решение, чтобы не велосипедить?

https?

https?

И в каком месте там авторизация и сессии?

И в каком месте там авторизация и сессии?

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

И в каком месте там авторизация и сессии?

В случае использования https для авторизации по большому счету достаточно простого ключа без какой-либо криптографии, т.к. соединение итак идет по защищенному каналу.

И, если делать про принципу KISS, то сессия тут вообще не нужна — проще передавать ключ при каждом запросе.

В случае использования https для авторизации по большому счету достаточно простого ключа без какой-либо криптографии

А если кто-то ключ перехватит? Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

проще передавать ключ при каждом запросе.

Чтобы ключ не подобрали тупым перебором, желательно его генерацию сделать не очень быстрой.

Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

Тогда делай авторизацию по https. На сервере проверяешь сертификат клиента, на клиенте сертификат сервера (если в твоей схеме такое организовать будет достаточно просто). А данные гоняешь как привычно. Сессию организуешь вручную, по session_id.

И в каком месте там авторизация

Разин все правильно сказал. Авторизация в обе стороны.

и сессии

per-request. Можешь куку с привязкой к client software отдать и запретить более 1 сессии на пользователя, если хочется.

Чтобы ключ не подобрали тупым перебором

Таймаут 100мс при неверной авторизации. И ограничение числа одновременных подключений.

А если кто-то ключ перехватит? Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

HTTPS обеспечивает защиту от прослушивания и атак Man-in-middle. Таким образом перехватить ключ можно только получив контроль над одной из систем, а в таком случае уже ничего не поможет.

Я конечно не берусь утверждать 100% надежность протокола HTTPS (где-то тут недавно дискуссия по этому поводу была), но вряд ли ты на коленке напишешь что-то лучше.

Задача-то, как я писал, не в организации защищённого канала. А в организации авторизации.

Наличие защищенного канала может помочь организовать авторизацию без изобретения ненужных велосипедов.

может просто посмотреть Kerberos ? http://ru.wikipedia.org/wiki/Kerberos

а дальше мучить голову как построить SSO (single sign on) на нём конкретно для вашего случая.

Для LDAP-AD доменов - всё вмеру разжёванно в сети. А вот кто ваши пользователи, как они представляются, где и как хранится/проверяется/генерятся ключи - придётся возможно выдумывать

Готовый и стандартный велосипед OAuth2

согласен с народом про серты с двух сторон.

лучше не мешать логику приложения с аутентификацией - пусть она остается в своем слое, пусть это будет https.

а сессии вроде как на сервисах не особо нужны - если это «типа сервис» (rest, soap, json,...) - большинство подразумевает stateless схемы обмена.

конечно подымать инфраструктуру PKI на пустом месте для «двух скриптов» напрягает, но можно по-минимуму обойтись CA.pl/CA.sh из комплекта openssl-я.

Https + sessionId в куках/хэдерах. Либо авторизация по клиентскому ключу. Не стоит изобретать велосипед там, где это не особо надо.

OAuth по https.