В 2009 году была выявлена атака на OAuth 1.0, в ходе которой злоумышленник инициировал последовательность авторизации OAuth, а затем убедил жертву завершить последовательность, результатом чего будет учетная запись злоумышленника на (честном) клиенте, которому назначены разрешения для ресурсы жертвы на (честной) RS.
OAuth 1.0a был пересмотренной версией спецификации, которая ослабила атаку.
В 2009 году, признавая ценность более формализованной стандартизации, это сообщество внесло OAuth 1.0 в IETF. Именно в Рабочей группе IETF первоначальный OAuth 1.0 был переработан и уточнен, чтобы стать Информационным
RFC 5849 .
В 2010 году Microsoft, Yahoo !, и Google создали протокол аутентификации веб-ресурсов (WRAP), который вскоре был представлен в рабочую группу IETF в качестве входных данных для OAuth 2.0. WRAP предложила существенную переработку модели OAuth 1.0a.
Среди изменений были устаревшие подписи сообщений в пользу SSL и формальное разделение между ролями «выдачи токенов» и «доверия токенами».
Разработка
OAuth 2.0следовательно, в IETF отражены входные данные как OAuth 1.0, OAuth 1.0a, так и предложения WRAP. Справедливо сказать, что совершенно разные предположения о том, какие надлежащие меры безопасности существуют между OAuth 1.0a и WRAP, создали напряженность в рабочей группе IETG OAuth.
Хотя
OAuth 2.0 первоначально отражал большую часть входных данных WRAP, в последнее время (то есть осенью 2010 г.) наблюдался групповой консенсус о том, что сигнатуры OAuth 1.0a, которые были объявлены устаревшими WRAP, являются подходящими и желательными в некоторых ситуациях. Следовательно, подписи должны быть добавлены обратно в качестве необязательного механизма безопасности.
Хотя многие развертывания OAuth 1.0a выживают, все больше и больше
OAuth 2.0развертывания появляются — обязательно против не окончательной версии спецификации. Например, Facebook, Salesforce и Microsoft Azure ACS используют черновой вариант 10 OAuth 2.0.
[Вышеприведенные абзацы являются прямыми выдержками из
официального документа, опубликованного Ping Identity для OAuth].
OAuth предоставляет клиентам способ доступа к ресурсам сервера от имени владельца ресурса (например, другого клиента или конечного пользователя). Он также предоставляет конечным пользователям процесс авторизации доступа третьих сторон к их ресурсам сервера без совместного использования их учетных данных (обычно пары имени пользователя и пароля) с использованием перенаправлений агента пользователя.
В традиционной модели аутентификации клиент-сервер клиент запрашивает ресурс с ограниченным доступом (защищенный ресурс) на сервере путем аутентификации на сервере с использованием учетных данных владельца ресурса. Чтобы предоставить сторонним приложениям доступ к ограниченным ресурсам, владелец ресурса делится своими учетными данными со сторонним. Это создает несколько проблем и ограничений.
1. Сторонние приложения должны хранить учетные данные владельца ресурса для будущего использования, как правило, пароль в виде открытого текста.
2. Серверы должны поддерживать аутентификацию по паролю, несмотря на недостатки безопасности, создаваемые паролями.
3. Сторонние приложения получают слишком широкий доступ к защищенным ресурсам владельца ресурса, в результате чего владельцы ресурсов не имеют возможности ограничивать продолжительность или доступ к ограниченному подмножеству ресурсов.
4. Владельцы ресурсов не могут аннулировать доступ к отдельной третьей стороне без аннулирования доступа ко всем третьим сторонам, и должны сделать это, изменив свой пароль.
5. Компрометация любого стороннего приложения приводит к компрометации пароля конечного пользователя и всех данных, защищенных этим паролем.
OAuth решает эти проблемы путем введения уровня авторизации и отделения роли клиента от роли владельца ресурса.
Протокол основывается на трехстороннем сценарии, делегируя пользователю доступ к потребителю для ресурсов, находящихся у поставщика услуг. Во многих случаях необходим двухсторонний сценарий, в котором
Потребитель действует от своего имени , без прямого или какого-либо участия Пользователя.
OAuth был создан для решения проблемы совместного использования двухсторонних учетных данных в трехсторонних ситуациях. Однако в контексте OAuth Потребителям, возможно, все же потребуется связаться с поставщиком услуг, используя запросы, которые зависят от потребителя. Поскольку Потребители уже установили Ключ потребителя и Секрет потребителя, важно иметь возможность использовать их для запросов, в которых проверяется личность Потребителя.
Эта спецификацияопределяет, как двухсторонний OAuth работает с OAuth 1.0. Но это никогда не стало IETF RFC.
С OAuth 1.0 — 2-х сторонний OAuth включает в себя две стороны. Потребитель и поставщик услуг. В основном в этом случае потребитель также становится владельцем ресурса. Потребитель должен сначала зарегистрировать customer_key и consumer_secret у поставщика услуг. Чтобы получить доступ к защищенному ресурсу, потребитель отправляет запрос HTTP (S) на URI конечной точки ресурса поставщика услуг. Запрос ДОЛЖЕН быть подписан, как определено в разделе 9 OAuth Core 1.0, с пустым секретным ключом.
Все запросы к Защищенным ресурсам ДОЛЖНЫ быть подписаны Потребителем и проверены Поставщиком услуг. Целью подписания запросов является предотвращение использования Ключом Потребителя неавторизованными сторонами при отправке запросов на Защищенные ресурсы. Процесс подписи кодирует Consumer Secret в проверяемое значение, которое включено в запрос.
OAuth не требует конкретного метода подписи, поскольку каждая реализация может иметь свои собственные уникальные требования. Протокол определяет три метода подписи: HMAC-SHA1, RSA-SHA1 и PLAINTEXT, но поставщики услуг могут свободно реализовывать и документировать свои собственные методы.
Потребитель объявляет метод подписи в параметре oauth_signature_method, генерирует подпись и сохраняет его в параметре oauth_signature. Поставщик услуг проверяет подпись, как указано в каждом методе. При проверке подписи Потребителя Поставщик услуг ДОЛЖЕН проверить одноразовый номер запроса, чтобы убедиться, что он не использовался в предыдущем запросе Потребителя.
Процесс подписи НЕ ДОЛЖЕН изменять имена или значения параметров запроса, за исключением параметра oauth_signature.
2-х сторонний OAuth с OAuth 1.0 — запрос к защищенному ресурсу будет выглядеть следующим образом.
http://provider.example.net/profile
Authorization: OAuth realm="http://provider.example.net/",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_signature="IxyYZfG2BaKh8JyEGuHCOin%2F4bA%3D",
oauth_timestamp="1191242096",
oauth_token="",
oauth_nonce="kllo9940pd9333jh",
oauth_version="1.0"
Этот пост в блоге объясняет на примере, как использовать 2-х сторонний OAuth с OAuth 1.0 для защиты сервиса RESTful.
Теперь давайте посмотрим на OAuth 2.0 — все еще на стадии проекта спецификации. Это не говорит о двуногом OAuth. Но — это может быть реализовано различными подходами, предложенными в OAuth 2.0.
Взгляните на
это и
это — оба расскажут о том, как реализовать двухсторонний OAuth с OAuth 2.0 — и эти обсуждения принадлежат рабочей группе OAuth 2.0 IETF.
OAuth 2.0 определяет четыре роли:
1. владелец ресурса: объект, способный предоставлять доступ к защищенному ресурсу (например, конечному пользователю).
2. сервер ресурсов: сервер, на котором размещены защищенные ресурсы, способный принимать и отвечать на запросы защищенных ресурсов с использованием токенов доступа.
3. клиент: приложение, делающее защищенные запросы ресурсов от имени владельца ресурса и с его авторизацией.
4. сервер авторизации: сервер, выдающий клиенту токены доступа после успешной аутентификации владельца ресурса и получения авторизации.
В случае двухстороннего OAuth клиент становится владельцем ресурса.
Мы можем на очень высоком уровне разделить весь поток OAuth на две части.
1. Получить токен с сервера авторизации.
2. Использовать токен для доступа к серверу ресурсов.
Давайте посмотрим, как работают два вышеупомянутых шага в двухстороннем OAuth.
OAuth 2.0 определяет концепцию, называемую «грант авторизации», которая представляет собой мандат, представляющий авторизацию владельца ресурса (для доступа к его защищенным ресурсам), используемую клиентом для получения токена доступа. Эта спецификация определяет четыре типа предоставления.
1. Код авторизации
2. Неявный
3. Учетные данные пароля владельца ресурса
4. Учетные данные
клиента «Учетные данные
клиента» — это тип предоставления, который тесно связан с двухсторонним OAuth.
С типом предоставления «Client Credentials» клиент может запросить токен доступа, используя только свои учетные данные клиента (или другие поддерживаемые средства аутентификации), когда клиент запрашивает доступ к защищенным ресурсам, находящимся под его контролем.
Как только клиент отправит этот запрос на сервер авторизации, он вернет обратно токен доступа для доступа к защищенному ресурсу.
Маркер доступа, возвращаемый клиенту, может быть носителем типа MAC.
Тип токена «mac», определенный в
ietf-oauth-v2-http-mac , используется путем выдачи ключа MAC вместе с токеном доступа, который используется для подписи определенных компонентов HTTP-запросов клиентом при доступе к защищенному ресурсу.
Схема MAC требует установления общего симметричного ключа между клиентом и сервером. Это часто выполняется с помощью ручного процесса, такого как регистрация клиента.
Спецификация OAuth 2.0 предлагает два метода для выдачи клиенту набора учетных данных MAC с помощью ..
1. OAuth 2.0 в форме токена доступа типа MAC с использованием любого поддерживаемого типа предоставления OAuth. [Это то, что мы обсуждали выше — токен доступа с типом ‘MAC’]
2. Поле заголовка ответа HTTP «Set-Cookie» через атрибут расширения.
При использовании токенов доступа типа MAC с двухсторонним OAuth — запрос к защищенному ресурсу будет выглядеть следующим образом.
GET /resource/1?b=1&a=2 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="264095:dj83hs9s",
mac="SLDJd4mg43cjQfElUs3Qub4L6xE="
Тип носителя определен
здесь . Это токен безопасности с тем свойством, что любая сторона, владеющая токеном («носитель»), может использовать токен любым способом, которым может воспользоваться любая другая сторона, обладающая этим токеном. Использование токена на предъявителя не требует, чтобы носитель доказал наличие материала криптографического ключа (подтверждение владения).
При использовании токенов доступа типа Bearer с двухсторонним OAuth — запрос к защищенному ресурсу будет выглядеть следующим образом.
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer vF9dft4qmT
Также — выданный токен доступа с Сервера авторизации на клиент имеет атрибут «область действия». [Двусторонний OAuth с OAuth 1.O не имеет этого атрибута области действия, а также концепции токенов доступа — поэтому сервер ресурсов должен выполнять авторизацию отдельно на основе клиента ресурса, который собирается получить доступ]
Клиент должен запрашивать токены доступа с минимальным Объем и срок службы необходим. Сервер авторизации будет учитывать идентификацию клиента при выборе способа соблюдения запрошенной области действия и срока службы и может выдать токен доступа с меньшими правами, чем запрошено.
При защите API с помощью OAuth — этот атрибут «scope» может быть привязан к различным API. Таким образом, сервер авторизации может решить, разрешить ли клиенту доступ к этому API или нет.