Хотелось бы знать мнение опытных программистов.

Задача такая:

У нашего портала есть партнеры, у которых есть собственные CMS. Они хотят иметь возможность регистрировать и авторизовывать пользователей на нашем портале через свои CMS. Партнеров много, CMS разные. Для этого им нужно предоставить некое единое Api. 

Пока что идея такая. 

1. Мы выдаем им уникальный md5 key. 
2. Они нам присылают POST запрос с этим ключом и всеми данными, включая логин и пароль.
3. Мы проверяем соответствует ли key домену с которого был прислан запрос.
4. Создаем пользователя у себя.
5. Для авторизации они будут использовать url наподобие domen.net/partner_login/client_id/12345/key/ad786asd76f7dfdfadf44f
где ad786asd76f7dfdfadf44f - md5(key+логин+пароль)

У меня нет опыта в обеспечении подобной секьюрности. Буду признателен за советы, замечания. Особенно, если кто-то уже делал подобное.

P.s. доступ к собственной базе давать нельзя.

Это сообщение отредактировал(а) Алексей - 6.6.2011, 10:48

советую копать в сторону SSL

Авторизация/регистрация должна проходить прозрачно для пользователя, или пользователь знает, что будет работать через аккаунт на вашем сайте?

Добавлено через 2 минуты и 53 секунды
В любом случае стоит взглянуть на OAuth (его как раз проектированли для авторизации приложений), а вот flow уже выбирать в зависимости от ваших потребностей.

Добавлено через 11 минут и 37 секунд

Для того, чтобы удедиться, что запрос пришел действительно с сайта-партнера, можно делать дополнительный запрос к ним, на который они должны отвечать что-то типа "да, запрос от меня" (так работают, например, paydpal IPN).

Вот эту часть стоит замнить на "POST запрос, подписанный этим ключем.". т.е. сам ключ не должен передаваться в открытом виде, а только искользоваться как ключ для шифрования (в простейшем варианте -- XOR)
Кроме  того, в сигнатуру запроса стоит добавить timestamp (если будет перехвачен один запрос, то воспользоваться им второй раз не получиться).

Спасибо за столь развернутый ответ.



Пользователь будет в курсе. Но схема работы для него будет примерно такая:
1. Авторизируется у себя на сайте.
2. Жмет кнопку.
3. Он уже на нашем сайте.

Про OAuth не слышал. Сейчас почитаю.

Про timestamp и feedback - отлично! Спасибо   

А вот про 

не совсем понял. Т.е. они весь POST шифруют у себя, а мы дешифрируем у себя? А про алгоритм шифровки/дешифровки устно договариваться? Или Вы не это имели в виду?

Это сообщение отредактировал(а) Алексей - 6.6.2011, 12:47

http://php.net/manual/en/book.openssl.php

Вы себе гененируете private key, и оставляете себе. Потом из этого ключа генерите кучу public key и отдаете их всем партнерам, которые будут пользоваться вашими API.

Теперь вы можете закриптовать любую инфу используя свой private key и отдать партнеру, который уже используя свой public key на своей системе декриптует эту инфу. Ну и наоборот.

Обычно, весь POST шифровать нет смысла. Шифруется сигнатура запроса, т.е., например, все параметры слепливаются в обну строку, она шифруется клиентом. Сервер повторяет  ту же операцию и сравнивает переданную и полученную сигнатруы. 


Обычно, сайтам-партнерам поставляется не только документация, но и клиент для вашего API. В самом клиенте все это делается прозрачно, ну а если решат писать свой, то методы составления сигнатуры в документации. Иногда, название алгоримта тоже передается параметром.


Вариант, который предлагает CruorVult, надежне, но сложнее. Я сталкивался с проблемами при использовании openssl  на очень небольшой длинне строкм (возможно, очень зависит от алгоритма). Впечатление о php-реализации этой билиотеки осталось очень негативное, но это было 3 года назад.
+ если партнеров много и они очнень разные (есть те, которые используют shared hosts), то использование openssl может оказаться проблемным для них.

Ясно. Всем спасибо!