OAuth не предназначен для аутентификации. Он нужен для того, чтобы ваше приложение или сайт могли от лица пользователя делать какие-то действия в гугле, мейле или еще где-нибудь, при этом, что это за пользователь вы можете и не знать.
Многие системы (мэйл, фб, вк и т. п.) позволяют после авторизации запросить данные о пользователе. То есть, если через OAuth запросить авторизацию, а потом, используя API сервиса и полученную авторизацию, получить данные о пользователе, то их можно использовать для аутентификации. Но это уже надо курить API каждого конкретного сервиса и напрямую к OAuth это не относится.
text/javascript выбрали потому что в браузерах по-дефолту application/json скачивается как файл. Не удобно дебажить, разработчики жаловались. REST API поправим
Либо можно зарегистрировать специальный протокол на ваше приложение и открывать авторизацию в стандартном браузере с соответствующим redirect_uri. Тогда магия кук сработает.
Да, я был не прав. Куки не шарятся между приложениями, поэтому пользователь не может быть сразу аутентифицирован, если только он не делал этого раньше в этом приложении.
«Встроенный браузер» в виде курла это хак системы ) Это авторизация по логину и паролю, только вместо одного запроса получается куча возни с курлом. Полноценный встроенный браузер обеспечивает несколько преимуществ:
* знакомый, понятный пользователю интерфейс
* если пользователь уже аутентифицирован на сервисе, то ему в приложении логин с паролем вводить не придется
* если пользователь аутентифицирован на сайте и уже авторизовывал приложение, то диалог запроса авторизации показываться не будет, будет сразу редирект с access token'ом
На счет API для почты. Действительно, для этого уже есть готовые стандартные протоколы, поэтому OAuth у нас реализован для «социальных» API — работы с друзьями, фотографиям, музыкой, личными сообщениями. Полный список доступных функций — api.mail.ru/docs/reference/rest/. В будущем, когда будет понятный общепринятый стандарт для интеграции OAuth с почтой, мы поддержим и его.
Разница в версиях стандарта. Твиттер и гугл используют oauth 1.0. Яндекс, Mail.Ru, Facebook и др. используют вторую версию. Вторая версия гораздо проще в реализации и понимании. Думаю, в будущем на нее перейдут все.
На самом деле, там практически user-agent flow из oAuth 2.0. Разница в названиях параметров и некоторых деталях. Когда начинали делать, спецификации еще не было.
В скором будущем приведем к стандарту, благо, js либа это абстрагирует.
пока можно оплачивать только одной смс. на край это можно обойти: положить смсками денег на какие-нибудь деньги@mail.ru, а потом заплатить с них. не удобно, конечно. подумаем над реализацией такой фичи.
Пока это будет нетривиальной задачей :) Можно сделать вот что: залить receiver.html на доступную из интернета машину и зарегистрировать сайт, потом прописать домен этого сайта у себя в hosts, чтобы браузер обращался локально (receiver.html залить на локальную тоже). Так как все кроссдоменное взаимодействие происходит внутри браузера, то девелоперская может не иметь внешнего ip.
У мэйл.ру есть давно работающая реализация openid — openid.mail.ru/
Открытое сегодня api дает гораздо больше возможностей, чем просто авторизация. Оно позволяет публиковать свою информацию внутри социальной сети и получать оттуда трафик.
Многие системы (мэйл, фб, вк и т. п.) позволяют после авторизации запросить данные о пользователе. То есть, если через OAuth запросить авторизацию, а потом, используя API сервиса и полученную авторизацию, получить данные о пользователе, то их можно использовать для аутентификации. Но это уже надо курить API каждого конкретного сервиса и напрямую к OAuth это не относится.
С content-type уточню в понедельник почему он у нас именно такой.
* знакомый, понятный пользователю интерфейс
* если пользователь уже аутентифицирован на сервисе, то ему в приложении логин с паролем вводить не придется
* если пользователь аутентифицирован на сайте и уже авторизовывал приложение, то диалог запроса авторизации показываться не будет, будет сразу редирект с access token'ом
На счет API для почты. Действительно, для этого уже есть готовые стандартные протоколы, поэтому OAuth у нас реализован для «социальных» API — работы с друзьями, фотографиям, музыкой, личными сообщениями. Полный список доступных функций — api.mail.ru/docs/reference/rest/. В будущем, когда будет понятный общепринятый стандарт для интеграции OAuth с почтой, мы поддержим и его.
Но, в принципе, там все настолько просто, что сильно меняться оно уже вряд ли будет.
В скором будущем приведем к стандарту, благо, js либа это абстрагирует.
На счет того, что с локальной машине не удобно разрабатывать, знаем, планируем улучшить этот аспект.
Возможность усправления скроллом сделаем.
Будем упрощать процесс для таких случаев.
Открытое сегодня api дает гораздо больше возможностей, чем просто авторизация. Оно позволяет публиковать свою информацию внутри социальной сети и получать оттуда трафик.