Как узнать auth key в приложении
Auth key, как правило, используется для авторизации пользователя на сторонних серверах. К примеру, социальная сеть «Вконтакте» запустила игру «Тюряга». Эта игрушка работает на ресурсе, который не имеет отношение к сайту «Вконтакте». Однако ресурс предоставил свои услуги и место для размещения приложения «Тюряга». В итоге получается, что Вы, войдя в социальную сеть с помощью своих данных, при переходе в игру остаётесь неизвестным гостем для сервера этого приложения. Поэтому, чтобы начать играть, необходимо также авторизоваться на сайте, где расположена сама игра.
В силу этого и был создан auth key. Простыми словами, можно сказать, что данный ключ – это логин и пароль стороннего приложения. Следовательно, для разных приложений конкретному пользователю присваиваются персональные ключи auth key. При этом во время авторизации на стороннем ресурсе, как правило, требуется указать не только персональный ключ, но и ID номер. Это и является главным отличием auth key от привычных для нас логина и пароля.
С назначением ключа разобрались. Оказывается не такой уж он загадочный. Теперь неплохо было бы понять: «А где, вообще, хранится этот auth key? И можно ли его найти?» Найти можно. Всё очень просто. Также как и все элементы сайта, ключ авторизации спрятан непосредственно в коде страницы ресурса, на котором размещено стороннее приложение. Чтобы понять, как его найти, обратимся к популярному браузеру «Chrome». С помощью этого WEB-обозревателя запускаем интересующее нас приложение и однократным кликом правой кнопки мыши в любом месте страницы вызываем всплывающее меню. В нём следует выбрать пункт под названием «Просмотр кода страницы». Нашему вниманию будет представлена страница с множеством непонятных символов. Естественно, во всём этом разбираться не надо. Достаточно нажать клавиши Ctrl+F, и ввести в появившемся поле начальные буквы интересующего элемента. В нашем случае вводим «auth». После этого на странице кода выделится ярким цветом слово, введённое в поле. Примерный вид нужной строки будет таким: «auth_key»: «e6b84623c311f08f15e8263dd2f3a48a». Здесь e6b84623c311f08f15e8263dd2f3a48a и есть тот самый Auth-key.
Во всех браузерах, отличных от Chrome, процедура поиска auth key почти одинаковая. Основное отличие в том, что при нажатии правой кнопки мыши во всплывающем меню вместо пункта «Просмотр кода страницы» может быть, что-то другое, но по смыслу похожее. В некоторых WEB-обозревателях код страницы можно просмотреть, нажав одновременно клавиши Ctrl+U. В остальном, последовательность действий та же, что описана в приведённом выше примере.
У многих я видел проблемы с узнаванием своего auth в играх.
Так вот можно добывать auth быстрее чем через проги.И так приступим:
1.Открываем вашь браузер(у меня файр фокс)
2.Заходим в приложение там где мы хотим узнать свой auth
3.Находим на панеле браузера "Вид" и там "исходный код страници"(можно просто заменить действием ctrl+U)
4.В открытую табличку нажимаем ctrl+f и в появившееся окно прописуем auth и дальше что будет в " это и будет ваш auth к этой игре
________________
Боятся надо не смерти,а пустой жизни!
Многие задаются вопросом как найти auth и id
Вот вам видео ответ:
Когда открыли исходный код жмем Ctrl+F после чего откроется поисковик в него вводим слово - auth_key и жмем F3
Кому лень смотреть видео читайте
я думаю только noob-ы незнают как id и auth key найти
я думаю только noob-ы незнают как id и auth key найти
полностью с тобой согласен
но на всякий случай, кому лень смотреть видео:
Запускаем необходимое приложение и жмем в любом пустом месте страницы Правую кнопку мыши и выбираем пункт Просмотр кода страницы. PS: Так же в некоторых браузерах достаточно войти на страницу с приложением и нажать Ctrl+U. После проделанного выше появитс страница с исходным кодом. теперь в ней необходимо найти Auth. Среди множества непонятных символов найдется волшебная строчка вида "auth_key":"74d5607f28d9051a5dc43h2jfe7dc8eb" где 74d5607f28d9051a5dc43h2jfe7dc8eb и есть Ваш Auth-key. (пиримечание : у некоторых браузеров пункт просмотр кода может отличаться, у оперы это исходный текст )Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
А ты не чё такой чувак
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
А ты не чё такой чувак
я знаю
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
А ты не чё такой чувак
я знаю
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
А ты не чё такой чувак
я знаю
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
А ты не чё такой чувак
я знаю
LOOL
Кому лень смотреть видео читайте
Понимаю ты уже опытный пользователь ,но есть же дети ,которые не понимают простого,ты же не сразу стал опытным правильно ?
Ну вот Пусть детишки тоже учаться
А ты не чё такой чувак
я знаю
а давайте секс в 3
гомосек.
гомосек.
гомосек.
гомосек.
есть такие люди на земле
Даааа Ток нубы этого не знают))
Мы используем сервисы в интернете, чаще всего даже не зная, каким образом они устроены и функционируют. Не задумываясь, как передается информация о нас между тем или иным сервисом, мы просто делаем переходы с сайта на сайт, с одного приложения в другое. При этом, конечно же, между тем или иным сервером проходит моментальный обмен информацией. Чтобы дать вам знать немного больше о том, как устроена передача информации в интернете, мы пишем эту статью. В ней мы расскажем, что такое auth key, где это применяется и какова его роль в повседневной работе каждого из нас.
Auth key - это.
Итак, как можно понять из самого сокращения, полной формой этого термина является словосочетание «authorization key», что с английского переводится как «ключ авторизации». Такое название в полной мере отображает роль этого механизма и его сущность. Ключ сам по себе является генерированным из 32 случайных символов кодом, который используется для авторизации пользователя на сторонних сервисах.
Объяснить, что такое auth key, можно так: чтобы сервис знал, что вы - это вы, он запрашивает ваш код, переданный другим сервисом. Таким образом, между собой интернет-ресурсы обмениваются информацией о вашем идентификаторе, позволяющем «узнавать» вас. При этом, от вас не нужно будут требовать повторной авторизации, например, путем ввода логина и пароля, или подтверждения с помощью пароля. По уникальному ключу вас «узнают» даже без вашего участия в один момент. Удобно, согласитесь.
Где применяется передача auth key?
После того как разобрались, что такое auth key, следует уточнить сферу его применения. На примере вы сможете разобраться в этой категории подробнее и яснее, чем просто прочитав определение.
Идентификационный номер (id) auth key применяется в наиболее распространенном виде в случае работы социальных сетей и приложений, которые работают на их платформе.
Не секрет, что все игры и приложения, доступные нам в сети «ВК» созданы не администраторами «Вконтакте», а сторонними разработчиками. Это значит, что какая-нибудь игра размещена физически не на серверах социальной сети, а где-нибудь отдельно.
Идем дальше: задача приложения - выполнять те команды и задачи, которые перед ним ставит пользователь, перешедший на его страницу. Но как осуществить этот процесс (запрос пользователя с серверов «Вконтакте», адресованный, скажем, игре «Wormix»)? Очень просто! Социальная сеть передает ваш уникальный ключ - auth key (VK в качестве примера будет наиболее доступным каждому из нас) - игре. В свою очередь, та сверяет ваш ключ с ключом человека, который создал ваш аккаунт и, если этот параметр совпадает, вас авторизуют. Интересно, правда?
Вам не нужно вводить пароль и логин, повторно подтверждая себя и авторизуясь. Нет, все происходит так, что пользователь даже не замечает, что обращается к стороннему ресурсу - приложению.
Как узнать мой auth key?
Примерно вы разобрались в том, что из себя представляет auth key. Как посмотреть его, и можно ли это сделать, рассмотрим в этом пункте нашей статьи.
Итак, поскольку авторизационный ключ передается между сетью и приложением при помощи вашего браузера, вы, конечно же, можете его найти и увидеть собственными глазами. Тем более, что эта характеристика не меняется и является вашим уникальным ключом при работе с социальными сетями (и не только).
Чтобы увидеть ее, можете зайти на сайт «ВК» и перейти в какое-нибудь приложение. Далее нам нужно обратиться к исходному коду страницы, на которой размещена игра - это делается с помощью «горячих клавиш» Ctrl + U. Нажав их, вы увидите белый лист с большим количеством цифр и букв. Это код сайта, его символьное отображение. Здесь нам нужно искать параметр «auth_key», поэтому эти слова можно начать вбивать в форме поиска по странице. Вызвать ее, кстати, можно сочетанием Ctrl + F. Далее будет показан параметр, который мы описывали.
Почему не стоит публиковать свой auth key где попало?
Ваш ключ авторизации - это уникальный параметр, по сути, позволяющий получать доступ к социальной сети (и не только). Фактически, это данные, равнозначные логину и паролю одновременно. Теперь вы понимаете, почему его не рекомендуется открывать посторонним? Если оставите этот ключ где-нибудь в сети, вполне возможно, что специалисты, знающие о том, что такое auth key, больше и умеющие имитировать его, смогут воспользоваться им в своих целях. Зачем вам это?
Манипуляции с auth key
На самом деле, манипулировать с ключом авторизации можете и вы. По крайней мере, так делают игроки некоторых популярных приложений «Вконтакте». Делается это следующим образом: нужно узнать auth_key пользователя, у которого больше достижений, чем у вас, после чего вы заходите на сервер под его ключом. Таким образом, сервис распознает вас как того игрока, и фактически вы попадаете в его аккаунт (в игре). Например, так обманывают в Wormix и «Тюряге» - популярнейших игрушках «Вконтакте». Такие же манипуляции, очевидно, возможны и с прочими приложениями.
Правда, мы не рекомендуем так делать. Если подменяется ключ авторизации с целью мошенничества - это противозаконно и аморально. В том же случае, если речь идет о накрутке игр и прочих развлекательных сервисов - то делать это вообще, на наш взгляд, бессмысленно. Суть игры и заключается в том, чтобы наслаждаться процессом, а не жульничать.
Прежде чем пользователи смогут отправлять запросы с помощью API, им обычно необходимо зарегистрироваться для получения ключа API или изучить другие способы аутентификации запросов. API-интерфейсы различаются по способу аутентификации пользователей. Некоторые API требуют включения ключа API в заголовок запроса, в то время как другие API требуют тщательной защиты из-за необходимости защиты конфиденциальных данных, подтверждения личности и обеспечения того, чтобы запросы не были подделаны. В этом разделе мы изучим аутентификацию и авторизацию, а также то, на чем следует сосредоточиться в документации.
Определяем термины
Во-первых, давайте определимся с некоторыми ключевыми терминами:
- Аутентификация: подтверждение правильности личности
- Авторизация: разрешение определенного действия
API может аутентифицировать, но не разрешит делать определенный запрос.
аутентификация и авторизация
Последствия нехватки безопасности API
Почему даже API-интерфейсы нуждаются в аутентификации? Для API, которые предназначены только для чтения, иногда пользователям не нужны ключи. Но большинство коммерческих API требуют авторизации в виде ключей API или других методов. Если нет никакой защиты API, пользователи могут совершать неограниченное количество запросов API без какой-либо регистрации. Разрешение неограниченных запросов усложнит модель дохода для вашего API.
Вдобавок, без аутентификации не было бы простого способа связать запросы с конкретными данными пользователя. И не было бы способа защиты от запросов от злонамеренных пользователей, которые могут удалить данные другого пользователя (например, путем удаления запросов DELETE для учетной записи другого пользователя).
Наконец, не получится отследить, кто использует API или какие конечные точки используются чаще всего. Очевидно, что разработчики API должны подумать о способах аутентификации и авторизации запросов к своим API.
В целом, аутентификация и авторизация с помощью API служат следующим целям:
Разные виды авторизации
Существует несколько методов авторизации. Ниже рассмотрим несколько вариантов авторизации, которые встречаются чаще всего:
API ключ
Большинство API требуют авторизации ключом API, чтобы использовать API. Ключ API представляет собой длинную строку, которую обычно включают либо в URL запроса, либо в заголовок запроса. Ключ API в основном служит способом идентификации лица, выполняющего запрос API (аутентифицируя для использования API). Ключ API также может быть связан с конкретным приложением, которое регистрируется.
Ключи APK используют строку в свойстве заголовка для авторизации запросов
API могут дать как открытый, так и закрытый ключ. Открытый ключ обычно включается в запрос, в то время как закрытый ключ рассматривается скорее как пароль и используется только при обмене данными между серверами. На некоторых сайтах документации API, при заходе на сайт, ключ API автоматически заполняется в примере кода и API Explorer.
Basic Auth
Другой тип авторизации называется Basic Auth. С помощью этого метода отправитель помещает пару имя пользователя:пароль в заголовок запроса. Имя пользователя и пароль кодируются с помощью Base64, который представляет собой метод кодирования, который преобразует имя пользователя и пароль в набор из 64 символов для обеспечения безопасной передачи. Вот пример Basic Auth в заголовке запроса:
В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:
Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.
Сервер API (получатель), получая запрос, принимает те же системные свойства (отметка времени запроса плюс идентификатор учетной записи) и использует секретный ключ (который известен только запрашивающей стороне и серверу API) и SHA для генерации одной и той же строки. Если строка соответствует подписи в заголовке запроса, запрос принимается. Если строки не совпадают, запрос отклоняется.
Вот диаграмма, отображающая процесс авторизации HMAC:
Важным моментом является то, что секретный ключ (критический для восстановления хэша) известен только отправителю и получателю. Секретный ключ не включается в запрос. Безопасность HMAC используется, когда нужно убедиться, что запрос является подлинным и не может быть подделан.
OAuth 2.0
Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.
окно входа в систему, использующую Oauth2.0
Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.
Three-legged OAuth используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:
- сервер аутентификации;
- сервер API;
- пользователь или приложение.
Вот базовый процесс Oauth2.0:
Сначала пользовательское приложение отправляет ключ приложения и секретные данные на страницу входа в систему на сервере аутентификации. Если аутентификация пройдена, сервер аутентификации возвращает пользователю токен доступа (авторизации).
Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).
Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer , за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.
Токены доступа (авторизации) не только обеспечивают аутентификацию для запрашивающей стороны, но и определяют права пользователя на использование API. Кроме того, токены доступа (авторизации) обычно истекают через некоторое время и требуют от пользователя повторного входа в систему. Для получения дополнительной информации об OAuth 2.0 можно посмотреть ресурсы:
Что документируется в разделе аутентификации
В документации API не нужно подробно объяснять внешним пользователям, как работает аутентификация. Отсутствие объяснений внутренних процессов аутентификации, является лучшей практикой, поскольку хакерам будет сложнее злоупотреблять API.
Тем не менее нужно объяснить необходимую информацию:
Если есть открытый и закрытый ключи, нужно объяснить, где следует использовать каждый ключ, и отметить, что закрытые ключи не должны использоваться совместно. Если разные уровни лицензий предоставляют разный доступ к вызовам API, эти уровни лицензирования должны быть явно указаны в разделе авторизации или в другом месте.
Поскольку раздел API ключей важен, и нужен разработчикам до того, как они начнут использовать API, этот раздел должен быть в начале руководства.
Образцы разделов авторизации
Ниже приведены несколько примеров разделов авторизации в документации API.
SendGrid
SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.
В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.
Amazon Web Services
Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.
Dropbox
Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.
👨💻 Практическое занятие: Авторизация
В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:
Читайте также: