Различия OAuth и OpenID

#авторизация #oauth #аутентификация #oauth2 #openid

Скажите, пожалуйста, чем отличаются OAuth и OpenID?
    

Ответы

Ответ 1

OpenID позволяет сайту удостовериться, что его пользователь владеет
  неким персональным URL (своим сайтом, блогом, профилем). Этого факта
  достаточно для того, чтобы использовать уникальный URL для узнавания
  того же самого пользователя в следующий раз. И всё. Все остальные вещи
  — заведение аккаунта, получение email'а и других данных, разрешение
  какой-то активности на сайте — остаётся на усмотрение сайта. Другими
  словами, OpenID — это чистая аутентификация: вы знаете, кто к вам
  пришёл, но вольны делать с этим знанием всё, что угодно.





  OAuth позволяет программе (на вебе или локальной) получить от
  пользователя права на использование какого-то конкретного API. Права
  обозначаются токеном, свойства которого никак не определены: он может
  быть одинаковым для разных пользователей, может быть разным для одного
  в разное время. Всё, что гарантируется — это что программа в обмен на
  токен сможет выполнять какие-то действия на каком-то сервисе. Другими
  словами, OAuth — это чистая авторизация: вы обладаете конкретными
  правами, но не можете в общем случае по ним определить, кому они
  принадлежат.





  Аналогия. OpenID — это ваш паспорт: он говорит, кто вы, но что он
  даёт, зависит от места, куда вы с ним пришли. OAuth — ключи от
  вашей машины: с ними можно ездить на вашей машине, даже не зная, как
  вас зовут.


Разница между OpenID и OAuth - Иван Сагалаев

ASP.NET Identity VS Самописная система авторизации

#c_sharp #aspnet #aspnet_mvc #oauth2 #aspnet_identity_2

Может показаться что это очень "холиварный" вопрос, но я всё же задам его.

Начинал писать свою систему ещё тогда, когда был в моде ASP.NET Membership. Ну естественно,
гибкости мне далеко не хватало и я решил писать свою систему авторизации, не опираясь
на какие-то устоявшиеся в те времена принципы разработки авторизационных/аутентификационных
систем. Что примерно из себя напоминает система сейчас:


Отдельный контекст (мало ли что в жизни бывает);
CodeFirst - реализация;
Хранение токена сессии в кукисах и сравнение его с токеном в отдельной таблице в БД.
Авторизационные фильтры типа ([IdentityFilter("admin", "user", "manager")]) и типа
([IdentityFilter(RolesEnum.Manager)]). На выбор ;)
Репозиторий.
Авторизационная информация получается в фильтре и далее гуляет в HttpContext`e.
Ну и много других мелочей.


Так вот, как бы работает быстро, но что то подсказывает мне, что можно ещё быстрее. 

Собственно хотелось узнать, какие преимущества может нести для меня Identity и целесообразно
ли его использование в "реальном продакшне", или же это интерфейс для новичков, и для
тех, кто не хочет парится.

Ведь в моём коде для меня нет никаких ограничений, а вот в Identity ограничения всё
таки есть, хотя бы то же самое именование таблиц и полей по умолчанию.

P.S. Прошу очень развёрнутый, и тем более аргументированный ответ. Заранее спасибо!
    

Ответы

Ответ 1

Membership забыл как страшный сон, перешел на Identity:


Нужна простая авторизация без лишней возни? - пожалуйста. Добавил подсистему и забыл.
Нужно использовать Claims? - пожалуйста. Не нужно? - можно добавить в любой момент,
а до тех пор хранить все основной таблице. А Claims так и будет ждать своего часа.
Нужно добавить авторизацию через соцсети? - пожалуйста.
Не нравятся именование полей или самой таблицы? - можно все переименовать.
Нужно добавить новое поле? - пожалуйста. Автоматическая миграция, ничего не нужно
удалять или бэкапить.
Необходима двухфакторная аутентификация с подтверждением по смс или электронной почте?
- Всё есть, просто добавить необходимые службы.
Дополнительные требования к логинам и паролям? - орудия пыток на выбор:

AllowOnlyAlphanumericUserNames,
RequireUniqueEmail
// -------------------
RequiredLength = 6,
RequireNonLetterOrDigit = false,
RequireDigit = false,
RequireLowercase = false,
RequireUppercase = false



и т.д. и т.п.

Проще в студии загрузить готовый шаблон и поковырять его пару вечерков, чтобы точно
убедиться подходит ли Identity для своих нужд.
Для загрузки рабочего примера с комментариями в консоли пишем «Install-Package Microsoft.AspNet.Identity.Samples
-Pre»

Update


Если нужно простое, гибкое, функциональное и готовое решение - Asp.net Identity подойдет.
Все в коробке.
Если необходимо реализовывать сложные сценарии: глубокие политики безопасности, одновременная
аутентификация по Active Directory, сертификатам, токенам, онлайн формам (как на всех
сайтах), то советую обратить внимание на Windows Identity Foundation. Придется несколько
попотеть.


Ответ 2

Холивар полнейшей -) 

Добавлю к ответу от товарища @Ice2burn - авторизация по клеймам возможна и достаточно
проста в написании. Я написал подобное и уже года полтора в продакшне использую с большим
успехом. Прототип можно поковырять здесь. 

Identity состоит на самом деле из нескольких пакетов:


Microsoft.AspNet.Identity.Core - в основном интерфейсы и базовые имплементации классов
которые не относятся к хранению данных
Microsoft.AspNet.Identity.EntityFramework - имплементации классов которые относятся
к хранению данных. Здесь все заточенно под EF, но все имплементации могут быть замененны
на кастомное хранилище. Я видел пакеты которые позволяют хранить информацю о юзерах
использую NHibernate или в RavenDb или Azure Tables. Так что хранилище может быть замененно
без проблем.
Microsoft.AspNet.Identity.Owin - адаптер для использования OWIN и создания кукисов
через OWIN. В принципе тоже можно заменить, но не могу придумать зачем это менять.


Claims - весьма удобная вещь. Все клеймы которые добавленны в запись юзера попадают
в authentication куки и их оттуда можно достать без проблем. Их можно не использовать,
но потратить полчаса на понимание как они работают и отказаться будет невозможно -).
Когда создается печенка для входа на сайт, все пользователькие роли на самом деле записываются
в куку как клеймы. Система потом достает из куки все клеймы с названием Role. То есть
хочешь-не хочешь а клеймы используются по дефолту. Можно даже сказать что роли это
по сути отдельный класс клеймов.

Еще одна очень удобная вещь в Identity это SecurityStamp - GUID на записи пользователя.
Если это поле меняется в базе, то сбрасываются все пользователькие куки и надо логиниться
по-новой. Так можно легко предотвращать двух людей которые логинятся с разных компов
под одним аккаунтом - полезно когда бизнес модель предполагает оплату по количеству
аккаунтов.

OAuth2.0 vk.com используя curl и bash

#vkontakte_api #bash #вконтакте #curl #oauth2

Я хочу написать баш скрипт, который будет взаимодействовать с контактом через апи.

Для начала необходимо запрограммировать OAuth2.0 авторизацию. Все казалось бы просто,
но проблема в том, что я не могу использовать браузер, так как хочу чтобы мой скрипт
работал на юниксовой машине без иксов и без вмешательства пользователя, то есть меня.

Исходя из документация сайта вконтакте сначала я должен выполнить GET запрос:

https://oauth.vk.com/authorize?client_id=&redirect_uri=https://oauth.vk.com/blank.html&display=mobile&scope=video,audio&response_type=token&v=5.44&revoke=1


Этот запрос выполняется нормально и я получаю страницу для отображения пользователю
с формами ввода. На данной странице меня интересует только следующий код:







Phone or email:





Password:






Cancel



Not registered yet?


Sign
up for VK




Исходя из документации и этого кода делаю вывод что должен реализовать следующее,
то есть отправить пост запрос:

https://login.vk.com/?act=login&soft=1&utf8=1


и в качестве параметров передать следующие поля:

_origin, ip_h, lg_h, to, email, pass


Но этот запрос у меня не работает. Возвращается пустая строка при попытке выполнить
через curl и страница с ошибкой, мол неправильный пароль если отправляю запрос через
какой-нибудь REST клиент. Была мысль что проблема может быть в том, что я не использую
куки, но с их добавлением тоже ничего не изменилось, хотя возможно я что-то сделал не так.

Скрипт, который я пытаюсь заставить работать:

#!/bin/bash
username=$1
password=$2

response=$(curl --cookie-jar vk.txt "https://oauth.vk.com/authorize" --data "client_id=&redirect_uri=https://oauth.vk.com/blank.html&display=mobile&scope=video,audio&response_type=token&v=5.44&revoke=1")
echo "response is $response"
echo "================================================================="
response=$(curl --request POST --cookie vk.txt "https://login.vk.com/?act=login&soft=1&utf8=1"
--data-urlencode "_origin=https://oauth.vk.com&ip_h=&lg_h=&to=&email=&pass=")
echo "response is $response"
echo "================================================================="

exit 0


Я пробовал играться с параметрами curl, например, кодировать, раскодировать передаваемые
данные запроса. Но в результате получаю одно и то же. Может быть я должен проводить
какое-то дополнительное кодирование или шифрование прежде чем выполнять запрос? Если
да, то почему curl не выполняет это по умолчанию?

Я нашел на просторах статью, где эта задача решалась на питоне и у чувака все работает.
Я воспользовался его питоновским кодом, переделав его под третий питон, но он также
не работает. Возвращает пустую страницу после ввода логина и пароля, хотя должен возвращать
страницу с разрешениями для приложения. Мне кажется, что механизм авторизации претерпел
некоторые изменения, в связи с чем код перестал работать. Вот ссылка на ту статью:
https://habrahabr.ru/post/143972/

Вообщем вопрос в следующем: как сделать так чтобы всё заработало или что я делаю не так?
    

Ответы

Ответ 1

А redirect_uri у вас соответствует тому, что вы указали при регистрации приложения?
Если нет, то проблема в этом.

Spring Security OAuth2

#java #spring #spring_security #oauth2

Есть сервис с авторизацией через OAuth2 (например, vk.com). Есть clientId и clientSecret.
Нужно написать демона, который будет делать какие-то запросы к API сервиса.

Возможно ли это сделать в фоновом режиме и автоматически получать access_token по
истечению срока? Например, многие сервисы после авторизации больше не запрашивают данные
пользователя.

UPD. Мне нужно сохранять access_token (например, в БД), а потом из обычного потока
работать с OAuth2RestTemplate.

public void run() {
    // access_token = получаем из БД сохраненный access_token.
    // создаем restTemplate из access_token
    while (true) {
        Map map = restTemplate.getForObject(..., Map.class);
    }
}

    

Ответы

Ответ 1

После долгих попыток рецепт получился следующим.


Получаем access_token из базы данных в новом потоке;
Оборачиваем его в DefaultOAuth2AccessToken;
Создаем DefaultOAuth2ClientContext и добавляем в него DefaultOAuth2AccessToken;
Создаем OAuth2RestTemplate с настройками и установленным контекстом.
Выполняем запросы и ловим UserRedirectRequiredException. Исключение означает, что
ключ больше не валидный и нужно запросить новый у пользователя через контроллер.

JavaScript Application и авторизация через OAuth 2

#php #javascript #angularjs #oauth2

Дано:


Основной сайт (PHP+HTML) с поднятым OAuth 2 сервером
Доверенное приложение на этом же домене на Angular-е (100% javascript)


Задача:


Авторизация пользователей в приложении через собственный OAuth сервер (точнее нужен
токен для доступа к апи)
"Запомнить меня" (каждый раз тыкать кнопку и делать кучку редиректов не вариант)


Размышления:

Сама спецификация предусматривает для таких случаев Implicit Grant, но как реализовать
"запомнить" я так и не придумал ибо срок жизни токена ограничен, а получить новый можно
только через редиректы => оно неюзабельно.

Кроме того, например, вон там рассказывается что оно не безопасно и дана гениальная
идея использовать proxy и шифрованные кукисы для скрытия токенов (refresh_token получается
недоступен в js, но сохраняется в кукисах и может потом использоваться повторно) -
однако, я так и не понял что помешает использовать этот proxy напрямую? (имхо, бессмысленное
усложнение, возможно, ошибаюсь?) 

Следующей после после proxy была идея забить на спецификацию и использовать Authorisation
Code Grant с открытым client_secret - благодаря наличию refresh_token-а можно будет
получать новые токены и оставаться авторизованным. НО этот вариант по сути мало чем
отличается от Implicit Grant с "вечным" токеном + из-за большего количества действий
реализация получается немного сложнее.

Решение?

В итоге после прочтения тонны всяких статей на тему js + oauth и размышлений о том
как же оно всё криво изложенных выше остановился на следующем варианте: используя Client
Credentials Grant выполняем ajax POST на основной сайт и если пользователь там авторизован
("там" оно определяется по cookies) и ранее уже авторизовал приложение, то сразу возвращаем
токен (это и будет "запомнить меня"), если нет, то получаем первый токен через Implicit
Grant. Естественно это всё только при https, POST, X-Frame-Options: DENY и всё на одном
домене. Вроде бы оно не сильно дыряво получается? 



В общем то, хотелось бы услышать критику или предложите какой-нибудь другой вариант,
себе уже всю голову сломал :(
    

Ответы

Ответ 1

Вы, ровно как и Алекс Билби сильно преувеличиваете опасность авторизации клиентских
приложений в OAuth2. 

Естественно, в фронтенде публичного веб-приложения не стоит организовывать получение
прав через Resource Owner Password Credentials(когда OAuth-серверу для получения токена
передаётся id приложения + логин/пароль пользователя). Не стоит использовать и Client
Credentials(OAuth-серверу передаётся только id приложения, а авторизация происходит
с использованием внешних систем - например через NTLM-хеш, либо через HTTP-basic-авторизацию).
Впрочем, оба этих способа очень специфичны, и абсолютное большинство OAuth-серверов
их просто-напросто не поддерживают...

Для авторизации остаются только Explicit(Authorization Code) и Implicit. 

Explicit требует наличия веб-сервера. При этом access token клиенту не передаётся
- клиентской стороне возвращается "статус" и "код авторизации", тот передаёт серверу
приложения, а он используя код авторизации получает от OAuth-сервера токен доступа.
Дополнительно(но не всегда обязательно) при получении токена доступа серверу приложения
требуется отправить "client secret" - специальный код/пароль, по которому определяется
подлинность вашего приложения, и без указания которого нельзя получить токен доступа.

Implict не требует наличия веб-сервера, при этом токен доступа возвращается в url.
И естественно "client secret" в этом случае не используется - OAuth-серверу отправляется
только id приложение, которое собственно по определению не является секретной информацией(любой
может просто скопировать его из url авторизации, даже при explicit-авторизации). 

Злоумышленник потенциально может украсть как токен доступа при Implicit авторизации,
так и авторизационные cookies вашего сайта. Основным каналом утечки при этом являются
XSS-уязвимости на вашем сайте, либо вредоносное ПО на компьютере пользователя.

Что злоумышленник получит в случае кражи токена доступа/cookies? Для практически
всё! И не важно, что применялась Explicit-авторизация и вы проксировали запросы - всю
необходимую информацию он получит через ваш сайт.

Основное преимущество "проксирования" состоит в том, что иногда поставщики OAuth-ресурсов
создают чересчур широкие scope, включающие заведомо больший функционал, нежели необходимо
вашему приложению(несмотря на спецификацию, требующую минимальность) - в этом случае
вы можете отрезать доступ к нежелательным ресурсам на уровне вашего бекенда. 

Но и минус тоже есть - при Explicit-авторизации, в случае взлома вашего сервера,
злоумышленник получит из хранилища токены доступа сразу всех пользователей приложения.
В случае же Implict-авторизации, взломав ваш сервер, злоумышленник токены доступа пользователей
сразу не получит(ему придется предваритально модифицировать код фронтенда, да выдирать
сохраненные на клиентской стороне токены).

Spring Security OAuth2

Есть сервис с авторизацией через OAuth2 (например, vk.com). Есть clientId и clientSecret. Нужно написать демона, который будет делать какие-то запросы к API сервиса.
Возможно ли это сделать в фоновом режиме и автоматически получать access_token по истечению срока? Например, многие сервисы после авторизации больше не запрашивают данные пользователя.
UPD. Мне нужно сохранять access_token (например, в БД), а потом из обычного потока работать с OAuth2RestTemplate
public void run() { // access_token = получаем из БД сохраненный access_token. // создаем restTemplate из access_token while (true) { Map map = restTemplate.getForObject(..., Map.class); } }

Ответ

После долгих попыток рецепт получился следующим.
Получаем access_token из базы данных в новом потоке; Оборачиваем его в DefaultOAuth2AccessToken Создаем DefaultOAuth2ClientContext и добавляем в него DefaultOAuth2AccessToken Создаем OAuth2RestTemplate с настройками и установленным контекстом. Выполняем запросы и ловим UserRedirectRequiredException. Исключение означает, что ключ больше не валидный и нужно запросить новый у пользователя через контроллер.

Различия OAuth и OpenID

Скажите, пожалуйста, чем отличаются OAuth и OpenID?

Ответ

OpenID позволяет сайту удостовериться, что его пользователь владеет неким персональным URL (своим сайтом, блогом, профилем). Этого факта достаточно для того, чтобы использовать уникальный URL для узнавания того же самого пользователя в следующий раз. И всё. Все остальные вещи — заведение аккаунта, получение email'а и других данных, разрешение какой-то активности на сайте — остаётся на усмотрение сайта. Другими словами, OpenID — это чистая аутентификация: вы знаете, кто к вам пришёл, но вольны делать с этим знанием всё, что угодно.

OAuth позволяет программе (на вебе или локальной) получить от пользователя права на использование какого-то конкретного API. Права обозначаются токеном, свойства которого никак не определены: он может быть одинаковым для разных пользователей, может быть разным для одного в разное время. Всё, что гарантируется — это что программа в обмен на токен сможет выполнять какие-то действия на каком-то сервисе. Другими словами, OAuth — это чистая авторизация: вы обладаете конкретными правами, но не можете в общем случае по ним определить, кому они принадлежат.

Аналогия. OpenID — это ваш паспорт: он говорит, кто вы, но что он даёт, зависит от места, куда вы с ним пришли. OAuth — ключи от вашей машины: с ними можно ездить на вашей машине, даже не зная, как вас зовут.
Разница между OpenID и OAuth - Иван Сагалаев

ASP.NET Identity VS Самописная система авторизации

Может показаться что это очень "холиварный" вопрос, но я всё же задам его.
Начинал писать свою систему ещё тогда, когда был в моде ASP.NET Membership. Ну естественно, гибкости мне далеко не хватало и я решил писать свою систему авторизации, не опираясь на какие-то устоявшиеся в те времена принципы разработки авторизационных/аутентификационных систем. Что примерно из себя напоминает система сейчас:
Отдельный контекст (мало ли что в жизни бывает); CodeFirst - реализация; Хранение токена сессии в кукисах и сравнение его с токеном в отдельной таблице в БД. Авторизационные фильтры типа ([IdentityFilter("admin", "user", "manager")]) и типа ([IdentityFilter(RolesEnum.Manager)]). На выбор ;) Репозиторий. Авторизационная информация получается в фильтре и далее гуляет в HttpContext`e. Ну и много других мелочей.
Так вот, как бы работает быстро, но что то подсказывает мне, что можно ещё быстрее.
Собственно хотелось узнать, какие преимущества может нести для меня Identity и целесообразно ли его использование в "реальном продакшне", или же это интерфейс для новичков, и для тех, кто не хочет парится.
Ведь в моём коде для меня нет никаких ограничений, а вот в Identity ограничения всё таки есть, хотя бы то же самое именование таблиц и полей по умолчанию.
P.S. Прошу очень развёрнутый, и тем более аргументированный ответ. Заранее спасибо!

Ответ

Membership забыл как страшный сон, перешел на Identity
Нужна простая авторизация без лишней возни? - пожалуйста. Добавил подсистему и забыл. Нужно использовать Claims? - пожалуйста. Не нужно? - можно добавить в любой момент, а до тех пор хранить все основной таблице. А Claims так и будет ждать своего часа. Нужно добавить авторизацию через соцсети? - пожалуйста. Не нравятся именование полей или самой таблицы? - можно все переименовать. Нужно добавить новое поле? - пожалуйста. Автоматическая миграция, ничего не нужно удалять или бэкапить. Необходима двухфакторная аутентификация с подтверждением по смс или электронной почте? - Всё есть, просто добавить необходимые службы. Дополнительные требования к логинам и паролям? - орудия пыток на выбор:
AllowOnlyAlphanumericUserNames, RequireUniqueEmail // ------------------- RequiredLength = 6, RequireNonLetterOrDigit = false, RequireDigit = false, RequireLowercase = false, RequireUppercase = false
и т.д. и т.п.
Проще в студии загрузить готовый шаблон и поковырять его пару вечерков, чтобы точно убедиться подходит ли Identity для своих нужд. Для загрузки рабочего примера с комментариями в консоли пишем «Install-Package Microsoft.AspNet.Identity.Samples -Pre»
Update
Если нужно простое, гибкое, функциональное и готовое решение - Asp.net Identity подойдет. Все в коробке. Если необходимо реализовывать сложные сценарии: глубокие политики безопасности, одновременная аутентификация по Active Directory, сертификатам, токенам, онлайн формам (как на всех сайтах), то советую обратить внимание на Windows Identity Foundation. Придется несколько попотеть.