Но, однако, переходя на новый способ, я заметил, что нигде в документации «В Контакте» не говорится, как сделать авторизационное окошко небольшим попапом.
На странице «Авторизация сайтов» сказано: «Для начала процесса авторизации необходимо создать окно браузера и открыть в нём диалог авторизации». Но ни слова не сказано о том, как создать такое окно.
У Facebook есть свой метод JavaScript FB.login для этой цели. У OpenAPI «В Контакте» есть VK.Auth.login. А для OAuth 2 «В Контакте» нет ничего.
«Ну что же, challenge accepted», — сказал я себе. И решил написать свой метод.
Вот что у меня получилось:
function vk_popup(options)
var
screenX = typeof window.screenX != ‘undefined’ ? window.screenX : window.screenLeft,
screenY = typeof window.screenY != ‘undefined’ ? window.screenY : window.screenTop,
outerWidth = typeof window.outerWidth != ‘undefined’ ? window.outerWidth : document .body.clientWidth,
outerHeight = typeof window.outerHeight != ‘undefined’ ? window.outerHeight : ( document .body.clientHeight — 22),OAuth в мобильных приложениях
width = options.width,
height = options.height,
left = parseInt(screenX + ((outerWidth — width) / 2), 10),
top = parseInt(screenY + ((outerHeight — height) / 2.5), 10),
features = (
‘width=’ + width +
‘,height=’ + height +
‘,left=’ + left +
‘,top=’ + top
);
return window.open(options.url, ‘vk_oauth’ , features);
>
function doLogin() var win;
var redirect_uri = ‘http://MY_APP/vk_auth/’ ;
var uri_regex = new RegExp(redirect_uri);
var url = ‘http://oauth.vkontakte.ru/authorize?client_id=CLIENT_IDredirect_uri=’ + redirect_uri;
win = vk_popup( width:620,
height:370,
url:url
>);
var watch_timer = setInterval( function () try if (uri_regex.test(win.location)) clearInterval(watch_timer);
setTimeout( function () win.close();
document .location.reload();
>, 500);
>
> catch (e)
Сначала создаю окно с диалогом авторизации, которое выглядит в точности, как аналогичное для OpenAPI.
Затем таймером отслеживаю изменение текущего URL в этом окошке, чтобы определить, когда «В Контакте» перенаправит на мой URL авторизации. И жду 500 мс, чтобы сервер уж точно успел обработать запрос. После этого перезагружаю основное окно своего сайта.
Обёртывать обращение к win.location в try <> catch(e) <> необходимо, потому что политика кросс-доменности не позволяет узнавать URL’ы окон других сайтов.
Хотелось также сделать это через какой-нибудь Observer, который бы наблюдал за изменением win.location и оповещал о событии, но подходящих примеров я не нашёл и JavaScript не моя основная специализация, поэтому остановился на реализации таймером. Буду благодарен, если кто-нибудь подскажет, как перевести на события.
Получение идентификатора приложения ID и Secret для Oauth2-авторизации через VK.COM «ВКонтакте»
Надеюсь, эта заметка будет полезной людям.
- социальные сети
- вконтакте
- oauth 2.0
- попап
- пользовательские интерфейсы
Источник: kildekode.ru
OAuth 2.0 простым и понятным языком
На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.
Что такое OAuth 2.0
OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
Чем отличаются OpenID и OAuth
Не смотря на то, что объяснений на эту тему уже было много, она по-прежнему вызывает некоторое непонимание.
OpenID предназначен для аутентификации — то есть для того, чтобы понять, что этот конкретный пользователь является тем, кем представляется. Например, с помощью OpenID некий сервис Ололо может понять, что зашедший туда пользователь, это именно Рома Новиков с Mail.Ru. При следующей аутентификации Ололо сможет его опять узнать и понять, что, это тот же Рома, что и в прошлый раз.
OAuth же является протоколом авторизации, то есть позволяет выдать права на действия, которые сам Ололо сможет производить в Mail.Ru от лица Ромы. При этом Рома после авторизации может вообще не участвовать в процессе выполнения действий, например, Ололо сможет самостоятельно заливать фотографии на Ромин аккаунт.
Как работает OAuth 2.0
Как и первая версия, OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров…
Ключевое отличие от OAuth 1.0 — простота. В новой версии нет громоздких схем подписи, сокращено количество запросов, необходимых для авторизации.
- получение авторизации
- обращение к защищенным ресурсам
- авторизация для приложений, имеющих серверную часть (чаще всего, это сайты и веб-приложения)
- авторизация для полностью клиентских приложений (мобильные и desktop-приложения)
- авторизация по логину и паролю
- восстановление предыдущей авторизации
Авторизация для приложений, имеющих серверную часть
- Редирект на страницу авторизации
- На странице авторизации у пользователя запрашивается подтверждение выдачи прав
- В случае согласия пользователя, браузер редиректится на URL, указанный при открытии страницы авторизации, с добавлением в GET-параметры специального ключа — authorization code
- Сервер приложения выполняет POST-запрос с полученным authorization code в качестве параметра. В результате этого запроса возвращается access token
Это самый сложный вариант авторизации, но только он позволяет сервису однозначно установить приложение, обращающееся за авторизацией (это происходит при коммуникации между серверами на последнем шаге). Во всех остальных вариантах авторизация происходит полностью на клиенте и по понятным причинам возможна маскировка одного приложения под другое. Это стоит учитывать при внедрении OAuth-аутентификации в API сервисов.
Пример
Здесь и далее примеры приводятся для API Mail.Ru, но логика одинаковая для всех сервисов, меняются только адреса страниц авторизации. Обратите внимание, что запросы надо делать по HTTPS.
Редиректим браузер пользователя на страницу авторизации:
> GET /oauth/authorize?response_type=code redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1.1 > Host: connect.mail.ru
Здесь и далее, client_id и client_secret — значения, полученные при регистрации приложения на платформе.
После того, как пользователь выдаст права, происходит редирект на указанный redirect_uri:
Обратите внимание, если вы реализуете логин на сайте с помощью OAuth, то рекомендуется в redirect_uri добавлять уникальный для каждого пользователя идентификатор для предотвращения CSRF-атак (в примере это 123). При получении кода надо проверить, что этот идентификатор не изменился и соответствует текущему пользователю.
Используем полученный code для получения access_token, выполняя запрос с сервера:
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_codeclient_secret=deadbeef redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 < HTTP/1.1 200 OK < Content-Type: application/json
Обратите внимание, что в последнем запросе используется client_secret, который в данном случае хранится на сервере приложения, и подтверждает, что запрос не подделан.
В результате последнего запроса получаем сам ключ доступа (access_token), время его «протухания GET /platform/api?oauth_token=SlAV32hkKGformat=json sig=. HTTP/1.1 > Host: appsmail.ru
Авторизация полностью клиентских приложений
- Открытие встроенного браузера со страницей авторизации
- У пользователя запрашивается подтверждение выдачи прав
- В случае согласия пользователя, браузер редиректится на страницу-заглушку во фрагменте (после #) URL которой добавляется access token
- Приложение перехватывает редирект и получает access token из адреса страницы
Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена authorization code на access token.
Пример
Открываем браузер со страницей авторизации:
> GET /oauth/authorize?response_type=token Host: connect.mail.ru
После того, как пользователь выдаст права, происходит редирект на стандартную страницу-заглушку, для Mail.Ru это connect.mail.ru/oauth/success.html:
Приложение должно перехватить последний редирект, получить из адреса acess_token и использовать его для обращения к защищенным ресурсам.
Авторизация по логину и паролю
Авторизация по логину и паролю представляет простой POST-запрос, в результате которого возвращается access token. Такая схема не представляет из себя ничего нового, но вставлена в стандарт для общности и рекомендуется к применению только, когда другие варианты авторизации не доступны.
Пример
Восстановление предыдущей авторизации
Обычно, access token имеет ограниченный срок годности. Это может быть полезно, например, если он передается по открытым каналам. Чтобы не заставлять пользователя проходить авторизацию после истечения срока действия access token’а, во всех перечисленных выше вариантах, в дополнение к access token’у может возвращаться еще refresh token. По нему можно получить access token с помощью HTTP-запроса, аналогично авторизации по логину и паролю.
Пример
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=refresh_tokenclient_secret=deadbeef HTTP/1.1 200 OK < Content-Type: application/json
Минусы OAuth 2.0
Во всей этой красоте есть и ложка дегтя, куда без нее?
OAuth 2.0 — развивающийся стандарт. Это значит, что спецификация еще не устоялась и постоянно меняется, иногда довольно заметно. Так, что если вы решили поддержать стандарт прямо сейчас, приготовьтесь к тому, что его поддержку придется подпиливать по мере изменения спецификации. С другой стороны, это также значит, что вы можете поучаствовать в процессе написания стандарта и внести в него свои идеи.
Безопасность OAuth 2.0 во многом основана на SSL. Это сильно упрощает жизнь разработчикам, но требует дополнительных вычислительных ресурсов и администрирования. Это может быть существенным вопросом в высоко нагруженных проектах.
OAuth — простой стандарт авторизации, основанный на базовых принципах интернета, что делает возможным применение авторизации практически на любой платформе. Стандарт имеет поддержку крупнейших площадок и очевидно, что его популярность будет только расти. Если вы задумались об API для вашего сервиса, то авторизация с использованием OAuth 2.0 — хороший выбор.
Со своей стороны, мы внедрили OAuth 2.0 в API Mail.Ru и, теперь, вы можете использовать возможности протокола для реализации любых клиентов и сервисов, интегрированных с Mail.Ru.
Ссылки
- Текущая версия драфта стандарта OAuth 2.0
- Официальный сайт OAuth
- Рабочая группа по выработке стандарта ( архивы)
- Документация по реализации OAuth 2.0 в Mail.Ru
Источник: h.amazingsoftworks.com
Реализация oAuth-регистрации в проектах ASP.NET MVC 4 на примере ВКонтакте
В предыдущей статье «Регистрация через oAuth провайдера в проектах ASP.NET MVC 4», было рассказано, как настроить приложение ASP.NET MVC 4, чтобы пользователи могли регистрироваться через Facebook. Но oauth-подключение для Facebook (также как и для Google, Twitter и др.) является встроенной возможностью в классе OAuthWebSecurity. Как быть, если нужно сделать регистрацию oauth-провайдера, которого нет в стандартной реализации? Рассмотрим такой случай на примере социальной сети ВКонтакте.
Итак, начнем. Создаем проект ASP.NET MVC 4 Web Application, выбираем шаблон Internet Application.
Создаем класс нового oAuth-клиента
Добавим к проекту папку Code и в ней создадим класс VKontakteAuthenticationClient.cs. Наследуем класс от IAuthenticationClient, для этого подключаем пространство DotNetOpenAuth.AspNet. Нам нужно реализовать одно свойство ProviderName, и два метода RequestAuthentication, и VerifyAuthentication. С ProviderName все просто, это что-то типа текстового идентификатора клиента.
Задать возвращаемое значение можно каким угодно, но лучше его сделать его читабельным и понятным: «vkontakte». Остальные два метода оставим пока как есть, их мы реализуем чуть позже.
using DotNetOpenAuth.AspNet; using System; using System.Collections.Generic; using System.Linq; using System.Web; namespace MvcApplication.Code < public class VKontakteAuthenticationClient : IAuthenticationClient < public string appId; public string appSecret; public VKontakteAuthenticationClient(string appId, string appSecret) < this.appId = appId; this.appSecret = appSecret; >string IAuthenticationClient.ProviderName < get < return «vkontakte»; >> void IAuthenticationClient.RequestAuthentication( HttpContextBase context, Uri returnUrl) < throw new NotImplementedException(); >AuthenticationResult IAuthenticationClient.VerifyAuthentication( HttpContextBase context) < throw new NotImplementedException(); >> >
И подключим наш новый класс клиента к проекту. В файле App_Start/AuthConfig.cs добавим в статический метод RegisterAuth такую строчку:
OAuthWebSecurity.RegisterClient( client: new VKontakteAuthenticationClient( «здесь будет app id», «здесь будет app secret»), displayName: «ВКонтакте», // надпись на кнопке extraData: null);
На данном этапе у нас есть подключенный клиент, который пока ничего не делает. Запустим проект и перейдем на страницу авторизации, там появилась кнопка ВКонтакте.
Далее зарегистрируем сайт у oauth-провайдера ВКонтакте и добавим код для двух методов клиента.
Источник: www.codehint.ru