Поток агента пользователя OAuth с настольным приложением C#

В настоящее время я пытаюсь использовать поток агента пользователя OAuth 2.0 с клиентским приложением C#, и у меня возникает некоторая путаница, связанная с URI перенаправления.

Поскольку я работаю с клиентским приложением, я не могу указать стандартный URL-адрес перенаправления на веб-сервер. Однако, по словам людей, с которыми я пытаюсь пройти аутентификацию (в данном случае Salesforce), поток User-Agent Flow является правильным для использования в клиентском приложении.

Мой вопрос: что я могу сделать, чтобы поймать токен доступа в этой ситуации? Видимо, я могу создать "локальный ресурс, доступный клиенту", но я не знаком с механикой этого и не могу найти ресурсы по теме (отчасти потому, что не знаю, что искать).

Любые указатели относительно того, где я должен начать искать, были бы очень признательны.


Изменить. Еще немного копания выявило следующий вопрос о переполнении стека:

Как вести локальную разработку с использованием OAuth?

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


Изменить: еще один поиск показал эту статью:

http://sarangasl.blogspot.com/2010/09/create-simple-web-service-in-visual.html

Все еще кажется, что я ковыряюсь в темноте, не понимая общей картины, но я считаю, что мне нужно настроить локальный веб-сервис, используя localhost, и указать там свой URI перенаправления. Затем я буду использовать свой веб-сервис, чтобы развернуть ответ от сервера OAuth, и мое приложение отреагирует соответствующим образом. Будут еще обновления.


Ооооооооооооооооооооооо Итак, из того, что мне удалось собрать, мне нужно настроить локальную веб-службу для использования в качестве обратного вызова для OAuth. Мне нужно самому прослушать указанную веб-службу и поймать обратный вызов, чтобы передать его моему приложению. Однако веб-служба ASP.NET по умолчанию, предоставляемая VS2010, не поддерживает параметры URL, а только вызовы API, поэтому вместо этого мне, по-видимому, нужно использовать стартовый комплект WCF Rest.

Я совершенно чужд всему этому, поэтому любые советы были бы находкой на данный момент. В общем, я думаю, что я настроил локальную службу WCF Rest, предоставил этот локальный URI для OAuth в качестве обратного вызова, а затем перехватил URL-адрес обратного вызова с помощью службы Rest. Затем я анализирую URL-адрес и извлекаю токен доступа. В этот момент мое приложение запрашивает токен доступа или моя веб-служба может «отдать» токен моему приложению? То есть, где должен быть локус контроля?


person sichinumi    schedule 31.05.2012    source источник


Ответы (3)


Придумал хитрый способ обойти это. Вместо того, чтобы настраивать службу для прослушивания URL-адреса перенаправления OAuth, я встроил элемент управления WebBrowser в свою форму Windows.

Я указал этому встроенному веб-браузеру URL-адрес аутентификации и позволил пользователю войти в систему и пройти аутентификацию с помощью Salesforce и предоставить разрешения моему приложению. Затем я разрешаю Salesforce перенаправить встроенный браузер на предоставленный мной фиктивный URL-адрес перенаправления. Этот редирект на самом деле никуда не ведет, он просто отображается как 404.

Однако, отслеживая WebBrowser.Url, я могу получить полный URL-адрес, на который направлен мой встроенный элемент управления WebBrowser, включая маркер доступа, добавленный Salesforce. По сути, после того, как пользователь аутентифицируется и предоставляет разрешения, встроенный браузер перенаправляется на «http://www.dummyurl.com». Salesforce добавляет токен доступа, поэтому WebBrowser.Url выглядит примерно так:

http://www.dummyurl.com#access_token=ABCDEF&instance_url=ABCDEF

Отсюда я могу просто проанализировать URL-адрес и продолжить свой путь. Не требуется сторонний веб-сервер или локальная веб-служба. :)

person sichinumi    schedule 01.06.2012
comment
Это был бы вариант. Но будьте осторожны: пользователь может использовать некоторые трюки в вашем веб-браузере, такие как переход вперед и назад в истории браузера, обновление страницы, тайм-ауты, отключение сети. ВАМ придется обрабатывать все коды ошибок HTTP + все неприятные уловки встроенного браузера. Удачи :) - person Artem Oboturov; 02.06.2012
comment
Плюс рассмотрите пользовательский интерфейс вашего приложения, который, вероятно, будет отличаться от того, который предлагает Salesforce, и вы не можете изменить их по умолчанию, потому что у вас нет контроля над ним. - person Artem Oboturov; 02.06.2012
comment
Угу, ты прав. Далее мне нужно будет взглянуть на встроенную безопасность браузера. Что касается пользовательского интерфейса, мое приложение является фоновым процессом, который генерирует всплывающее окно при определенных событиях, поэтому аутентификация требуется только один раз при запуске приложения (обычно один раз в день, утром). Однако спасибо за советы, я забыл о дырах в безопасности, которые потенциально могут быть открыты с помощью встроенного экземпляра IE. - person sichinumi; 02.06.2012

Вызов нужного вам типа авторизации Автономный клиент http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com#Obtaining_a_Token_in_an_Autonomous_Client_.28Username-Password_Flow.29. Прочтите об URL-адресе, который вы должны отправить туда.

grant_type=password&client_id=<your_client_id>&client_secret=<your_client_secret>&username=<your_username>&password=<your_password>
person Artem Oboturov    schedule 01.06.2012
comment
Я не могу использовать этот поток, к сожалению. Если IP-адрес, пытающийся пройти аутентификацию, не занесен в белый список, пароль должен быть дополнен токеном безопасности пользователя, что не подходит для моего приложения. - person sichinumi; 01.06.2012
comment
Поставьте его через свой прокси, который будет в белом списке. Плюс ссылка POSTed - поэтому параметры запроса будут зашифрованы по HTTPS. У вас есть проблемы с этим подходом? - person Artem Oboturov; 02.06.2012
comment
Хм, я не думал проксировать это. Однако я разрабатываю это приложение для других пользователей в других бизнес-средах, и маршрутизация всего трафика через сторонний прокси-сервер невозможна. У меня также нет контроля над белыми списками для разных организаций моих пользователей. Наконец, разработчики API прямо сказали мне избегать потока OAuth с паролем пользователя. Однако лично у меня нет проблем с этим, но взгляните на мой другой ответ и дайте мне знать, что вы думаете об этом. :) - person sichinumi; 02.06.2012
comment
Вы можете предоставить пользователю токены безопасности - в этом случае вам не нужно помещать их IP в белый список. Перечитайте последнюю часть документа об автономном клиенте. - person Artem Oboturov; 02.06.2012
comment
Я перечитал документ, но не нашел того, на что вы ссылались - пользователь должен быть единственным человеком, способным сгенерировать собственный токен безопасности, я не могу сделать это за них. Несмотря на это, по мнению специалистов по Salesforce API, поток пользовательских паролей — это зло и зло. :П - person sichinumi; 02.06.2012
comment
› Пароль пользователя API Salesforce.com. Если IP-адрес клиента не внесен в белый список вашей организации, вы должны соединить токен безопасности с паролем. - прямо из описания password. - person Artem Oboturov; 02.06.2012

Вы можете использовать библиотеку DotNetOpenAuth. Существует пример использования WPF, где используется элемент управления winforms с именем ClientAuthorizationView, предоставленный библиотекой DotNetOpenAuth.

Это элемент управления, в котором размещается браузер, позволяющий пользователю авторизовать клиента, не выходя из приложения.

Надеюсь, это поможет.

С уважением

person dave    schedule 28.05.2013