OAuth авторизация
OAuth – по определению означает Open Authorization. Поскольку в английском языке слова аутентификация (authentication) и авторизация (authorization) имеют одинаковое начало auth, то сокращение oauth очень неоднозначное. Эти понятия (авторизацию и аутентифакцию) очень часто путают друг с другом.
Например OpenID – это система для аутентификации.
Очень кратко про аутентификацию и авторизацию (т.к. это простые и занудные понятия).
Если примитивно, то аутентификация – это, например, когда на вахте человек показывает пропуск или удостоверение, а вахтер смотрит и соображает “пропуск настоящий или нет? правильная печать? фотка совпадает? и т.д. “.
Другими словами проверяет валидный пропуск или нет.
Аутентификация может быть простой (логин/пароль), а может быть и очень замысловатой. Например бывалые вахтеры часто используют Face Recognition Authentication.
На веб-сайтах за вахтера эту работу осуществляет модуль аутентификации, который заставляет нас вводить логин и пароль, а затем проверяет их правильность.
После успешной аутентификации, наступает процесс авторизации.
Например, вахтер понял – пропуск настоящий, а вот можно ли пускать этого человека в здание или нет?
Например вполне может быть следующая ситуация – в выходной день в здание можно попасть только боссу или охраннику, а предъявитель пропуска – обычный человек, которого даже нет в списках работающих по выходным (или после 22-00)! Так что успешно пройденная аутентификация еще не значит, что человек сможет пройти туда, куда хотел.
Другими словами, мы при авторизации “даем добро” на определенные действия, при этом как правило на момент авторизации мы уже отаутентифицировали пользователя.
Например, в нашем случае с вахтером при успешной “авторизации” человеку выдают пенал с ключами и он пойдет по своим делам.
При этом, важно то, что в результате проделанной вахтером авторизации, человеку выдаются только определенные permissions.
Таким образом, используя OAuth мы можем определять к чему будет доступ у аутентифицированного пользователя.
Например, мы можем ограничить доступ к только общей информацию или же предоставить доступ к возможности отправлять от своего имени сообщения, менять статус, получить к информации в любое время и т.д.
Другими словами, если открытая аутентификация – это когда мы отдаем на сторону проверка логина+пароля,
то при открытой авторизации мы уже можем делать больше – управлять разрешениями.
OAuth поддерживает Facebook и Twitter.
Общая схема работы следующая:
1. Отсылаем браузер на страницу аутентификации (допустим на Facebook или Twitter).
2. Пользователь видит родную фейсбучную страничку и не боясь вводит логин/пароль.
(картинка с сайта facebook-а)
3. Если все ОК. показывает страничку в которой спрашивает: “Дать право доступа к функции X?”
4. Если все ОК, браузер редиректит обратно, на URL нашего веб-сайта (какой именно URL мы указываем в п.1).
5. Обрабатываем редирект. В параметре редирект запроса к нам приходит “код доступа”.
6. С кодом доступа и секретом, отправляем запрос на получение токена (ACCESS_TOKEN).
7. Отправляем прикладные запросы с токеном (например получить информацию о пользователе: https://graph.facebook.com/me?access_token=ACCESS_TOKEN ).
На фейсбуке всё очень подробно показано и рассказано: http://developers.facebook.com/docs/authentication/
Схема работы:
Android
В случае если вы разрабатываете приложение под Андроид, то засада на редиректе (шаг 4).
Например, в случае приложения под Android:
0. Нажимаете условную кнопку [Вход в систему].
1. Стартуем Activity (браузер) для обработки Intent-а с нужным URL-ом для авторизации.
2. Открывается встроенный браузер.
3. Вводим логин/пароль и ….
Дальше возникает вопрос, как нам вернуться назад, в наш исходный Activity?
Основная хитрость в redirect URL. Мы придумываем его в виде myapp://success и настраиваем наше Activity
так, что именно оно должно уметь отлавливать такие урлы:
...
В итоге, после успешной авторизации браузер поймет, что нужно запустить Activity, которое может обработать этот странный URL “myapp://success”.
А теперь вся правда в деталях.
1. Обязательно нужно указать в intent-filter, что бы Activity отлавливала запросы от браузера.
Подробнее читать здесь: http://developer.android.com/reference/android/content/Intent.html#CATEGORY_BROWSABLE
...
2. Чтобы не мучиться, можно указать что Activity – singleInstance.
Тогда обработку запроса можно будет безболезненно сделать в переопределенном методе onNewIntent.
3. Важно! Facebook не даст вставлять какие попало URL-ы!
Так что придется брать строчку из примера: REDIRECT_URI = “fbconnect://success”
Еще раз, указывать надо не “myapp://”, а именно “fbconnect://“.
4. Далее с Facebook, ситуация такая. Использовать библиотеки signpost смысла нет, замучаетесь прикручивать.
Для Twitter-а signpost работает нормально, примеры использования растиражированы на многих блогах.
Самый правильный способ – использовать готовое Facebook API для андроида.
Очень подробная инструкция в картинках есть на сайте Facebook-а: https://developers.facebook.com/docs/mobile/android/build/
Если все-таки этот путь вам не подходит или вы слишком упрямый, нужно учесть еще следующее:
5. В случае с Facebook лучше указывать параметр display=touch.
Т.е. что-то вроде:
http://www.facebook.com/dialog/oauth?client_id=APP_ID&redirect_uri=fbconnect://success&display=touch
Тогда сразу будет показываться компактная и удобная форма для аутентификации.