Предположим, пользователь запускает приложение в соц.сети, например вконтакт, а приложение обращается к внешнему серверу. Каким образом сервер может удостовериться, что этот пользователь именно тот, за кого себя выдаёт, а не какой-то злоумышленник имитирует его, с корыстными целями? Нужно чтобы клиентское приложение передало серверному приложению какой-то ключ, который ему передаёт соц.сеть, которое в свою очередь попробует обратиться к апи соц.сети при помощи этого ключа?

AbstractionКот Дивуар,

Сертификат, не?
Хмм, а как он поможет? Их на каждого пользователя нужно?

AbstractionКот Дивуар,

Идея сертификата: я создаю сертификат (Priv, Pub), публикую (отсылаю через общедоступный канал, в отношении которого считается, что хакер может за ним наблюдать, но не искажать информацию в нём) пару (Pub, [подтверждение того, что я это я, скажем, ФИО]). После этого, когда я хочу связаться с "сервером", тот генерирует случайное число из большого диапазона и шифрует его с помощью Pub. Я его получаю и расшифровываю с помощью Priv (хакер это сделать не может, я никому Priv не передаю, а без него не обойтись), после чего отсылаю расшифрованное число и команду обратно серверу. Он понимает, что я прислал загаданное им число (хакер его не мог просто угадать, так как число из большого диапазона), и на основании этого с чистой душой выполняет команду.
Хмм, но я не вижу тут аутентификации юзера. Тут только защита от подмены юзера в процессе работы.

AbstractionКот Дивуар,

Есть связывание пользователя "на том конце провода" с некоторой ранее опубликованной информацией. Соответственно, можно связать "пользователя на том конце провода сейчас" с "пользователем, с которым был сеанс связи три месяца назад". То есть, презюмируя что три месяца назад это был не хакер, мы выводим что это не хакер и сейчас.
В Вашей схеме первого поста, клиентское приложение, условно говоря, ключ не "передаёт", а "демонстрирует".
А, то есть ключ бы шифровать надо, при передаче. Ну ясно. Плюс неким образом генерировать уникальный идентификатор пользователя на своём сервере, при первом обращении пользователя, а потом по описанной вами технологии, в следующие сеансы удостоверяться что это он.

Хотя не, в том алгоритме юзер сам должен сертификат где-то хранить, а мне так не подходит.

AbstractionКот ДивуарХотя не, в том алгоритме юзер сам должен сертификат где-то хранить, а мне так не подходит.То есть? Тогда раскройте смысл словосочетанияавторпользователь именно тот, за кого себя выдаётА именно, что значит "выдаёт" и что значит "тот".
Что он к примеру не декомпилировал программу (хотя тут можно обфускатором помешать), или ещё как-то не подставил чужой id, так как эта информация вконтакте открытая.

AbstractionКот ДивуарЧто он к примеру не декомпилировал программу (хотя тут можно обфускатором помешать), или ещё как-то не подставил чужой id, так как эта информация вконтакте открытая.
???
Проверка программой себя на модификацию - это действие параллельное работе с удалённым сервером. Сервер должен считать, что пакеты ему прислал кто угодно, а не обязательно именно эта программа.
Да не, пофигу на модификацию, главное чтобы юзер был именно тем, за кого себя выдаёт.

AbstractionКот Дивуар,

Ещё раз - чем отличается, в Вашем понимании, "выдавать" от "быть"? Либо эксклюзивной информацией a.k.a. "пароль", либо прошлой историей общения, которая тогда должна быть преобразована в некоторую, хранящуюся на компьютере либо в голове пользователя информацию.
Выдавать, это подсовывать серверу чужой id пользователя.
Быть, это говорить серверу свой собственный id пользователя.

AbstractionКот ДивуарВыдавать, это подсовывать серверу чужой id пользователя.
Быть, это говорить серверу свой собственный id пользователя.
Что значит "собственный"? Тот, для которого я знаю также пароль "ВКонтакте"? Тогда следует попросить "ВКонтакте" провести проверку, без этого никак. Вопрос, делает ли он это...
Да у них дока мерзкая, по этой теме уже не раз перечитывал, непонятно. Ладно, попробую на днях некоторые идеи.