что такое авторизироваться на сайте
Что значит авторизация на сайте и для банковской карты. Какие возникают ошибки
Приветствую вас на блоге inetsovety.ru. Для того, чтобы пользователю зайти на какой-либо сайт или сервис, ему необходимо зарегистрироваться. Человек вводит свои данные, придумывает логин, пароль, благодаря которым он становится зарегистрированным пользователем. Чтобы войти на сайт, человек должен в соответствующее окошко на странице авторизации ввести свои логин и пароль. Так система понимает, кто именно зашел в сервис. Это и есть авторизация пользователя.
Что значит авторизоваться на сайте на примере Яндекса
Понятие авторизация в современном мире встречается все чаще, поэтому нужно знать, что значит авторизуйтесь, когда появляется сообщение, где написано «требуется авторизация».
Рассмотрим процесс авторизации в Яндексе поэтапно:
По завершении эти пяти шагов вам удастся авторизоваться в Яндексе.
Подобную процедуру ввода логина и пароля вам потребуется проделывать на многих сайтах, где вы захотите совершить действие, но не сможете. Система попросит ввести данные для входа. Этот процесс запрашивается практически на каждом сайте, форуме, в интернет-магазинах, социальных сетях. Это дает пользователям некоторые привилегии, например, авторизованные участники форума могут оставлять свои комментарии, а не просто читать переписку других пользователей, а пройдя авторизацию в социальной сети, также можно просматривать профили людей, добавлять в список друзей, подписываться, писать сообщения.
В интернет-магазинах заказ осуществить могут только авторизованные пользователи, потому что при регистрации они указывают свои контактные данные и адрес.
Теперь вы знаете, что такое авторизация на сайте, поэтому не пугайтесь, когда система просить вас авторизоваться, это обычная процедура входа в свой аккаунт.
Какие бывают ошибки авторизации
Ошибка авторизации – это неверный ввод логина или пароля от сервиса. Если так произошло, то система укажет, что логин или пароль введены некорректно. Для того, чтобы решить проблему, нужно убедиться, что вы точно вводите правильные данные, исключить ошибки, возможно, был пропущен какой-либо символ, а также проверить раскладку клавиатуры и нажатие клавиши caps lock, которая все символы делает заглавными.
Если вы проверили все данные по вышеуказанным рекомендациям, но система все-равно не дает войти, то вероятнее всего, вы забыли пароль. В таком случае тоже предусмотрено решение. Просто нажмите на кнопку «забыли пароль», и система сбросит ваш старый код и предложит придумать новый в случае, если вы подтвердите, что это действительно ваш аккаунт. Как правило, сброс пароля происходит либо через привязанный к сайту номер телефона, либо через прикрепленный к сервису почтовый ящик.
Что может случиться при ошибке авторизации
Авторизация банковской карты и код авторизации
Банковские карты достаточно плотно ворвались в нашу жизнь. Сейчас люди все чаще проводят оплату по безналичному расчету, оплачивают товары в онлайн через интернет-кассы. Во-первых, безналичная оплата более безопасна с точки зрения сохранности средств: купюры вы можете потерять, а при утере пластиковой карты вы сможете обратиться в банк, заблокировать счет, а затем перевыпустить. Во-вторых, безналичная оплата безопаснее тем, что не надо контактировать с деньгами, которые передаются из рук в руки сотни раз в день, собирая множество бактерий.
Что такое авторизация банковской карты? Это процесс, при котором банк-эмитент дает разрешение на совершение денежной операции с использованием средств на счете. Но в банковской системе тоже бывают различные сбои, например, деньги на карте есть, а оплата не проходит, терминал фиксирует неполадки, а кассир просит пользователя назвать код авторизации. Многих такой запрос вводит в ступор, поэтому давайте разберемся, как авторизовать банковскую карту, и что же такое код авторизации.
Если вы задаетесь вопросом: предавторизация по карте, что это, то объясним поэтапно. Клиент, расплачиваясь в магазине по безналу, вводит данные своей карты, такие как пин-код, или прикладывает карту к pos-терминалу. Затем банк, который обслуживает данный магазин, отправляет запрос в ваш банк-эмитент для проведения транзакции. В этот момент клиент может увидеть на экране терминала надпись «авторизация». Это и есть предавторизация или холдирование средств. Банк-эмитент проверяет, если ли средства на карточке, в достаточном ли они количестве, затем переводит сумму денег на счет магазина. Этот процесс называется транзакцией, причем каждой такой операции присваивается код авторизации, который является неким разрешением вашего банка на списание денежных средств.
Код авторизации – это уникальная шестизначная комбинация цифр.
Запомните, что код авторизации, логин, пароль, код доступа в приложение вашего банка – это разные понятия. Разберемся, в каких случаях система запрашивает код авторизации:
Таким образом, код авторизации обеспечивает дополнительную защиту средств на вашей карте. Если произошел сбой в момент оплаты, значит, вам поступит смс с кодом. Если вы не совершали платежей в этот момент, следует немедленно обратиться к представителю вашего банка для блокировки счета или заблокировать карту в личном кабинете клиента.
Для входа в личный кабинет пользователю также нужно авторизоваться. Для этого в поисковой строке браузера ввести название своего банка, войти на официальный сайт, перейти в личный кабинет, затем в соответствующие окошки ввести логин и пароль, то есть авторизационные данные.
Через личный кабинет также можно проводить операции, не выходя из дома, переводить деньги, оплачивать ЖКХ, пополнять мобильный и др. Шестизначная комбинация присваивается каждой проведенной транзакции, поэтому код авторизации на чеке Сбербанка, который выдается банкоматом, тоже присутствует.
Что такое авторизация
Понятие авторизации простыми словами
Вы никогда не задумывались над тем, что такое авторизация и для чего она нужна? Потому что в современном мире, это понятие встречается всё чаще.
Авторизация присутствует на большинстве современных сайтов, и она полностью бесплатная для пользователей. Но в то же время, встречаются и отдельные, платные сервисы, требующие от пользователя некоторую сумму денег для проведения авторизации с доступом к платному контенту.
Это относительно новый тренд, который появился вместе с доступом к высокоскоростному, беспрерывному интернету. Перед тем, как пользователь может совершить авторизацию, ему нужно заполнить определённую анкету с указанием некоторой информации относительно своей личности.
Это важно для создания домена с оригинальным логином и паролем, которые человек будет использовать при входе на ресурс.
Стоит сказать несколько слов о том, что такое логин и пароль. Логин – это своего рода уникальное наименование, которое пользователь сам придумывает для себя, чтобы получить доступ к сайту. Он обязательно должен быть уникальным, иначе авторизоваться на сайте будет невозможно.
Касательно пароля, всё несколько проще. Это кодовое слово, состоящее из разной последовательности разных символов. В пароль входят, как буквы верхнего и нижнего регистра, так и цифры.
С помощью пароля, человек может подтвердить, что именно он является владельцем страницы, на которую был зарегистрирован тот или иной логин. Поэтому нужда в пароле объясняется целями безопасности.
Поэтому многие сайты сначала рекомендуют пользователю хорошо подумать и взять себе максимально оригинальный, сложный пароль. При желании, если с фантазией у пользователя туго, можно воспользоваться специальными генераторами пароля.
Благодаря которым появляется возможность получить максимально безопасный пароль, приложив при этом минимальное количество усилий.
Что собой представляет сам процесс авторизации?
Авторизация на данный момент является самой важной функцией, присутствующей на современных сайтах. Пользователи интернета сталкиваются с данной функцией на ежедневной основе.
При том на каждом возможном сайте. Это может быть какой угодно ресурс, социальная сеть, форум, интернет-магазин, сайт банка или любой другой веб-сайт. На нём в той или иной степени присутствует авторизация.
Благодаря регистрации на веб-сайте, человек автоматически получает некоторые привилегии по сравнению с обычными пользователями.
В случае тех же социальных сетей – это возможность видеть других пользователей, отправлять им сообщения, просматривать фотографии и так далее.
В интернет-магазинах, после регистрации появляется возможность совершать покупки. Потому что в процессе создания своей учётной записи, пользователь самостоятельно уже указывает по какому адресу ему нужно доставлять товар и на какое имя его оформлять.
Почему вообще происходит регистрация пользователя на сайте?
Вы наверняка не раз задавались вопросом о том, зачем вообще нужна регистрация на современных сайтах. Но на самом деле всё просто – при помощи регистрации пользователя на ресурсе, можно получить о нём некоторую информацию, а также наложить определённые ограничения.
Тем самым можно организовать работу определённых сервисов, которые позволяют людям упростить жизнь.
Но зачем создавать нужду в авторизации и искусственным образом ограничивать функции, которые пользователь мог и так получить?
Потому что было бы гораздо проще, если бы пользователь мог просто зайти на ресурс и сразу же использовал всё, что на нём представлено.
Ведь регистрация процедура хоть и лёгкая, но отнимает некоторое время. Особенно если говорить о случаях, когда пользователи забывают собственные пароли и начинают восстанавливать их при помощи электронной почты.
Однако есть причина, по которой обойтись без авторизации просто невозможно. Это в первую очередь мера предосторожности от спама. Потому что на ресурс могут обрушиваться пользователи, желающие причинить лишь только вред.
От того они активно начинают засорять ресурс различным текстовым хламом. С помощью элементарной регистрации удаётся избавиться от этих, так называемых, ботов. К тому же, авторизация, это своего рода процесс идентификации.
Информацию от вас никто не требует. Вы сами вводите её добровольно. Но при этом сайты берут на себя ответственность за сохранность предоставленных вами данных. Они постараются приложить максимум усилий, чтобы никто и ни при каких условиях не смог узнать ваше имя, почтовый адрес и многое другое.
Таким образом можно выделить огромное количество преимуществ авторизации, которые позволяют ей оставаться важным элементом любого современного веб-сайта:
Идентификация, аутентификация и авторизация — в чем разница?
Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.
Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.
Ничего такого уж страшного в этом нет — пока идет бытовое общение и обе стороны диалога по контексту понимают, что в действительности имеется в виду. Но всегда лучше знать и понимать слова, которые употребляешь, а то рано или поздно нарвешься на зануду-специалиста, который вынет всю душу за «авторизацию» вместо «аутентификации», кофе среднего рода и такое душевное, но неуместное в серьезной беседе слово «ихний».
Идентификация, аутентификация и авторизация: серьезные определения
Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:
Объясняем идентификацию, аутентификацию и авторизацию на енотах
Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:
Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.
Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.
А вот авторизация без идентификации и тем более аутентификации очень даже возможна. Например, в Google Документах можно публиковать документы так, чтобы они были доступны вообще кому угодно. В этом случае вы как владелец файла увидите сверху надпись, гласящую, что его читает неопознанный енот. Несмотря на то, что енот совершенно неопознанный, система его все же авторизовала — то есть выдала право прочитать этот документ.
А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.
А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.
Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:
Что такое авторизация?
При входе посетителей на сайт, в систему банковских платежей, требуется авторизоваться. Что такое авторизация? Это процесс подтверждения прав на совершение определенных операций – управления счетом, снятия средств, изменения данных. Он необходим для обеспечения безопасности при совершении действий, для разграничения прав пользователей, для защиты от злоумышленников. Используется на сайтах, в банкоматах, пропускниках, Интернет-магазинах. Обычно пользователь должен ввести свой логин (имя) в системе и пароль (кодовое слово, набор символов). Если коды введены правильно, разрешается вход в систему и выполнение разрешенных манипуляций. Если допущена ошибка, вход в систему не производится.
Ошибка авторизации
Ошибка авторизации – неверное введение логина, пароля и других данных. При наборе кодовых слов, пользователь должен обращать внимание на правильный порядок символов, регистр, установленную раскладку клавиатуры. При ошибке авторизации система блокирует посетителя доступ к системе и может производить такие действия:
Код авторизации
Код авторизации представляет собой набор символов, которые хранятся в памяти системы и позволяют идентифицировать права пользователя. В качестве кода обычно выступают комбинации 3-12 букв, цифр, знаков, набранных в определенной последовательности. Код авторизации генерируется в процессе регистрации пользователя и впоследствии может изменяться по желанию владельца учетной записи или по требованию службы безопасности. Часто устанавливается определенное ограничение на количество изменений комбинаций в период времени. Для безопасного пользования сервисом, пользователь должен хранить набор символов в тайне.
Авторизация в личном кабинете
Авторизация в личном кабинете позволяет пользователю получить доступ к изменению настроек своей учетной записи, интерфейса взаимодействия с системой, паролей, типовых операций, на управление счетом, внесение изменений в систему. До выполнения авторизации, посетитель сайта или банковского учреждения может использовать ограниченный набор функций: просматривать общедоступную информацию, проводить транзакции, не требующие подтверждения прав доступа. Часто при авторизации в личном кабинете используют дополнительные средства безопасности – ввод капчи, подтверждение по SMS или e-mail.
Онлайн авторизация
Онлайн авторизация позволяет пользователям использовать сервисы без личного посещения финансовых учреждений, магазинов, учебных заведений. Для этого нужно войти на сайт, перейти по соответствующей ссылке или нажать на определенную кнопку, ввести данные в форму. Онлайн авторизация помогает посетителям ресурса экономить время, а организациям – делать услуги доступными широким массам, привлекать большее количество клиентов, улучшать качество обслуживания, повышать степень безопасности выполнения операций, проводить статистические исследования, ранжировать права доступа пользователей.
Авторизация недоступна
При входе в систему, пользователю может быть выдано сообщение о том, что авторизация недоступна. В этом случае посетителю следует попробовать повторно авторизоваться, выполнив все требования безопасности, выполнить восстановление забытого пароля или логина или обратиться в службу технической поддержки по телефону или e-mail. Сообщение «Авторизация недоступна», выдается посетителю сайта или пользователю сервиса в следующих случаях:
Данные авторизации
Авторизация банковской карты
Авторизация банковской дебетовой карты – это получение права на совершение транзакций с помощью «пластика», доступа к управлению счетом. Выполняется в режиме онлайн – на сайте финансового учреждения или офлайн – с помощью POS-терминала. Для авторизации необходимо ввести определенные данные: пароль, логин, PIN-код, проверочные слова, коды из SMS. При попытке получения несанкционированного доступа, подбора пароля, система безопасности может временно блокировать аккаунт пользователя. Для восстановления прав пользования сервисом, нужно обратиться в учреждение, выдавшее «пластик», лично или по телефону.
Виды режимов авторизации
Для удобства пользователей, для использования имеющейся в наличии аппаратуры и для обеспечения выполнения требований безопасности, созданы различные виды режимов авторизации. Часто используется комбинация нескольких таких режимов. Различают такие их типы:
Плюсы авторизации
Плюсы авторизации для пользователей: возможность получить доступ к большему количеству функций сервиса, управлять личными данными, повысить степень защиты своих средств, конфиденциальной информации.
Неавторизованным пользователям обычно открыт доступ к базовым сервисам, ограниченному количеству функций и к публичной информации. Плюсы авторизации для компании: идентификация клиентов и сотрудников, простое разграничение прав доступа, повышение степени безопасности и защиты конфиденциальной информации, учет и регулирование количества посетителей сервиса.
Авторизация и аутентификация для всех
Аутентификация и авторизация необходимы для многих приложений. Допустим, вы разработали приложение и внедрили в него аутентификацию и авторизацию — использовали для этого стороннюю библиотеку аутентификации или платформу идентификации. Выполнив свою работу, как обычно вы не стали разбираться, что происходит за кулисами, или почему что-то происходит определенным образом. Но если вы хотите получить общее представление о том, что происходит на самом при использовании стандартов OAuth 2.0 и OpenID Connect, читайте дальше!
Аутентификация — это сложно. Почему так? Стандарты Auth хорошо определены, но в них сложно разобраться. И это нормально! Мы собираемся пройти через это максимально доступным способом. Мы рассмотрим концепции идентификации шаг за шагом, опираясь на наши знания по мере продвижения вперед. К тому времени, когда мы закончим, вы должны иметь фундамент и знать, куда нужно обратиться если вам нужно будет больше информации.
Введение
Когда я говорил семье или друзьям, что я «работаю в identity», они часто предполагали, что это означает, что я работал в правительстве, в организации выдающей водительские права, или что я помогал людям разрешать мошенничество с кредитными картами.
Однако ни то, ни другое не было правдой. Ранее я работал в компании Auth0,, которая управляет цифровой идентификацией. (Сейчас я являюсь участником программы Auth0 Ambassadors и являюсь экспертом Google Developer по SPPI: Security, Privacy, Payments, and Identity — безопасность, конфиденциальность, платежи и идентификация.)
Цифровая идентификация
Цифровая идентификация это набор атрибутов, которые определяют отдельного пользователя в контексте функции, предоставляемой конкретным приложением.
Скажем, вы управляете компанией по продаже обуви онлайн. Цифровой идентификацией пользователей вашего приложения может быть номер их кредитной карты, адрес доставки и история покупок. Их цифровая идентификация зависит от вашего приложения.
Это приводит нас к …
Аутентификация
В широком смысле, аутентификация относится к процессу проверки того, что пользователь является тем, кем он себя заявляет.
Как только система сможет установить это, мы приходим к …
Авторизация
Авторизация касается предоставления или отказа в правах доступа к ресурсам.
Стандарты
Вы можете вспомнить, что я упомянул, что аутентификация основывается на четко определенных стандартах. Но откуда эти стандарты берутся?
Есть много разных стандартов и организаций, которые управляют работой Интернета. Два органа, которые представляют для нас особый интерес в контексте аутентификации и авторизации, — это Инженерная рабочая группа по Интернету (Internet Engineering Task Force — IETF) и Фонд OpenID (OpenID Foundation — OIDF).
IETF (Internet Engineering Task Force)
IETF — это большое открытое международное сообщество сетевых инженеров, операторов, поставщиков и исследователей, которые занимаются развитием интернет-архитектуры и бесперебойной работой интернета.
OIDF (OpenID Foundation)
OIDF — это некоммерческая международная организация людей и компаний, которые стремятся обеспечить, продвигать и защищать технологии OpenID.
Теперь, когда нам известны спецификации и кто их пишет, давайте вернемся к авторизации и поговорим о:
OAuth 2.0
OAuth 2.0 является одной из наиболее часто упоминаемых спецификаций, когда речь идет о сети, а также часто неправильно представленной или неправильно понятой.
OAuth не является спецификацией аутентификации. OAuth имеет дело с делегированной авторизацией. Помните, что аутентификация — это проверка личности пользователя. Авторизация касается предоставления или отказа в доступе к ресурсам. OAuth 2.0 предоставляет доступ к приложениям от имени пользователей.
Как было до OAuth
Чтобы понять цель OAuth, нам нужно вернуться назад во времени. OAuth 1.0 был создан в декабре 2007 года. До этого, если нам требовался доступ к сторонним ресурсам, это выглядело так:
Допустим, вы использовали приложение под названием HireMe123. HireMe123 хочет настроить событие календаря (например, встречу на собеседование) от вашего имени (пользователя). HireMe123 не имеет собственного календаря; поэтому нужно использовать другой сервис под названием MyCalApp для добавления событий.
После того, как вы вошли в HireMe123, HireMe123 запросит у вас ваши учетные данные для входа в MyCalApp. Вы должны ввести свое имя пользователя и пароль на сайте HireMe123.
Затем HireMe123 используя ваш логин получить доступ к API MyCalApp, и затем сможет создавать события календаря с использованием ваших учетных данных.
Совместное использование учетных данных — это плохо!
Этот подход основывался на совместном использовании личных учетных данных пользователя из одного приложения с совершенно другим приложением, и это не очень хорошо.
Так как, HireMe123 поставил на карту защиты вашей учетной записи MyCalApp гораздо меньше. Если HireMe123 не защитит ваши учетные данные MyCalApp надлежащим образом, и они в конечном итоге будут украдены или взломаны, кто-то сможет написать несколько неприятных статей в блоге, но HireMe123 как бы останется в стороне.
HireMe123 также получает слишком большой доступ к MyCalApp от вашего имени. HireMe123 получает все те же привелегии, что и вы, потому что он использовал ваши учетные данные для получения этого доступа. Это означает, что HireMe123 может читать все ваши события календаря, редактировать их, изменять настройки и т. д.
Появление OAuth
Все эти недостатки приводит нас к OAuth.
OAuth 2.0 — это открытый стандарт для выполнения делегированной авторизации. Это спецификация, которая говорит нам, как предоставить сторонним пользователям доступ к API без предоставления учетных данных.
Используя OAuth, пользователь теперь может делегировать HireMe123 для вызова MyCalApp от имени пользователя. MyCalApp может ограничить доступ к своему API при вызове сторонними клиентами без риска совместного использования информации для входа или предоставления слишком большого доступа. Это делается с помощью:
Сервер авторизации
Сервер авторизации — это набор конечных точек (методов API) для взаимодействия с пользователем и выдачи токенов. Как это работает?
Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь у нас есть OAuth 2.0:
MyCalApp теперь имеет сервер авторизации. Предположим, что HireMe123 уже зарегистрирован как известный клиент в MyCalApp, что означает, что сервер авторизации MyCalApp распознает HireMe123 как объект, который может запрашивать доступ к своему API.
Предположим также, что вы уже вошли в систему с HireMe123 через любую аутентификацию, которую HireMe123 настроил для себя. HireMe123 теперь хочет создавать события от вашего имени.
HireMe123 отправляет запрос авторизации на сервер авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — войти в систему с помощью MyCalApp (если вы еще не вошли в систему). Вы аутентифицируетесь с MyCalApp.
Затем сервер авторизации MyCalApp запросит у вас согласие разрешить HireMe123 получать доступ к API MyCalApp от вашего имени. В браузере откроется приглашение, в котором будет запрошено ваше согласие на добавление в календарь событий HireMe123 (но не более того).
Если вы скажете «да» и дадите свое согласие, то сервер авторизации MyCalApp отправит код авторизации в HireMe123. Это позволяет HireMe123 знать, что пользователь MyCalApp (вы) действительно согласился разрешить HireMe123 добавлять события с использованием пользовательского (вашего) MyCalApp.
MyCalApp затем выдаст токен доступа для HireMe123. HireMe123 может использовать этот токен доступа для вызова MyCalApp API в рамках разрешенных вами разрешений и создания событий для вас с помощью MyCalApp API.
Ничего плохо больше не происходит! Пароль пользователя знает только MyCalApp. HireMe123 не запрашивает учетные данные пользователя. Проблемы с совместным использованием учетных данных и слишком большим доступом больше не являются проблемой.
А как насчет аутентификации?
На данный момент, я надеюсь, стало ясно, что OAuth предназначен для делегированного доступа. Это не распространяется на аутентификацию. В любой момент, когда аутентификация включалась в процессы, которые мы рассмотрели выше, вход в систему осуществлялся любым процессом входа в систему, который HireMe123 или MyCalApp реализовали по своему усмотрению. OAuth 2.0 не прописывал, как это должно быть сделано: он только покрывал авторизацию доступа сторонних API.
Так почему же аутентификация и OAuth так часто упоминаются вместе друг с другом?
Проблема входа в систему
То, что происходит после того, как OAuth 2.0 установил способ доступа к сторонним API, заключается в том, что приложение также требуется регистрировать пользователей у себя. Используя наш пример: HireMe123 нужно, чтобы пользователь MyCalApp мог залогиниться, используя свою учетную запись MyCalApp, даже несмотря на то, что он не был зарегистрирован в HireMe123.
Но, как мы упоминали выше, OAuth 2.0 предназначен только для делегированного доступа. Это не протокол аутентификации. Но это не помешало людям попытаться использовать его и для аутентификации, и это представляет проблему.
Проблемы с использованием токенов доступа для аутентификации
Если HireMe123 предполагает успешный вызов API MyCalApp с токеном доступа, достаточным что бы пользователь считался аутентифицированным, у нас возникают проблемы, поскольку у нас нет способа проверить, был ли выдан токен доступа правильному пользователю.
Это называется запутанной проблемой делегирования. HireMe123 не знает, откуда взялся этот токен и кому он был выдан. Если мы помним: аутентификация — это проверка того, что пользователь — это тот, кем он себя заявляет. HireMe123 не может знать это из-за того, что он может использовать этот токен доступа для доступа к API.
Как уже упоминалось, это не остановило людей от неправильного использования токенов доступа и OAuth 2.0 для аутентификации. Быстро стало очевидно, что формализация аутентификации поверх OAuth 2.0 была необходима, чтобы разрешить входы в приложения сторонних разработчиков, сохраняя безопасность приложений и их пользователей.
OpenID Connect
Это подводит нас к спецификации под названием OpenID Connect, или OIDC. OIDC — это спецификация OAuth 2.0, в которой говорится, как аутентифицировать пользователей. OpenID Foundation (OIDF) является руководителем стандартов OIDC.
OIDC — это уровень идентификации для аутентификации пользователей на сервере авторизации. Помните, что сервер авторизации выдает токены. Токены представляют собой закодированные фрагменты данных для передачи информации между сторонами (такими как сервер авторизации, приложение или API ресурса). В случае OIDC и аутентификации сервер авторизации выдает токены ID.
ID Токены
Идентификационные токены предоставляют информацию о событии аутентификации и идентифицируют пользователя. Идентификационные токены предназначены для клиента. Это фиксированный формат, который клиент может анализировать и проверять, чтобы извлечь идентификационную информацию из токена и тем самым аутентифицировать пользователя.
OIDC объявляет фиксированный формат для токенов ID, которым является JWT.
JSON Web Token (JWT)
JSON Web Tokens, или JWT (иногда произносится как «jot»), состоит из трех URL-безопасных сегментов строки, соединенных точками. Сегмент заголовка, сегмента полезной нагрузки и крипто сегмента.
Сегмент заголовка
Первый сегмент является сегментом заголовка (header segment). Он может выглядеть примерно так:
Сегмент заголовка — это объект JSON, содержащий в закодирован виде алгоритм и тип токена. Он закодирован в base64Url (байтовые данные представлены в виде текста, который является URL-адресом и безопасным для имени файла).
Декодированный заголовок выглядит примерно так:
Сегмент полезной нагрузки
Второй сегмент — это сегмент полезной нагрузки (payload segment). Он может выглядеть так:
Это объект JSON, содержащий фрагмент данных называемый claim, который содержат информацию о пользователе и событии аутентификации. Например:
Оно также кодируется в base64Url.
Крипто сегмент
Последний сегмент — крипто сегмент (crypto segment) или подпись (signature). JWT подписаны, поэтому они не могут быть изменены в процессе использования. Когда сервер авторизации выдает токен, он подписывает его с помощью ключа.
Когда клиент получает идентификационный токен, он также проверяет подпись с помощью ключа. (Если использовался алгоритм асимметричной подписи, для подписи и проверки используются разные ключи; в этом случае только сервер авторизации может подписывать токены.)
Claim
Claim можно перевести как требование, утверждение или как заявление.
Теперь, когда мы знаем об анатомии JWT, давайте поговорим подробнее об claim, этом фрагменте данных из сегмента полезной нагрузки. Согласно его названию, токены ID предоставляют идентификационную информацию, которая присутствует в формуле claim.
Аутентификационный Claim
Некоторые строки аутентификации в токене ID включают:
Одноразовый номер nonce привязывает запрос авторизации клиента к полученному токену. Одноразовый номер — это криптографически случайная строка, которую клиент создает и отправляет с запросом авторизации. Затем сервер авторизации помещает одноразовый номер в токен, который отправляется обратно в приложение. Приложение проверяет, совпадает ли одноразовый номер в токене с отправленным с запросом авторизации. Таким образом, приложение может проверить, что токен пришел из того места, откуда он запросил токен.
Идентификационные данные (Identity Claim)
Claim также включают информацию о конечном пользователе. Вот несколько примеров таких данных:
Некоторые из стандартных строк профиля в токене ID включают:
После того как мы рассмотрели спецификации OAuth 2.0 и OpenID Connect пришло посмотреть, как применить наши знания в области идентификации.
Аутентификация с помощью ID токенов
Давайте посмотрим на OIDC аутентификацию на практике.
Обратите внимание, что это упрощенная схема. Есть несколько разных потоков в зависимости от архитектуры вашего приложения.
Наши объекты здесь: браузер, приложение, запущенное в браузере, и сервер авторизации. Когда пользователь хочет войти в систему, приложение отправляет запрос авторизации на сервер авторизации. Учетные данные пользователя проверяются сервером авторизации, и если все хорошо, сервер авторизации выдает идентификационный токен приложению.
Затем клиентское приложение декодирует маркер идентификатора (который является JWT) и проверяет его. Это включает в себя проверку подписи, и мы также должны проверить данные claim. Вот некоторые примеры проверок:
После того как мы установили подлинность токена ID, пользователь проходит аутентификацию. Теперь у нас есть доступ к identity claims и мы знаем, кто этот пользователь.
Теперь пользователь аутентифицирован. Пришло время взаимодействовать с API.
Доступ к API с помощью токенов доступа
Мы немного поговорили о токенах доступа ранее, еще когда мы смотрели, как делегированный доступ работает с OAuth 2.0 и серверами авторизации. Давайте посмотрим на некоторые детали того, как это работает, возвращаясь к нашему сценарию с HireMe123 и MyCalApp.
Токены доступа
Токены доступа (Access Token) используются для предоставления доступа к ресурсам. С токеном доступа, выданным сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.
В отличие от токенов ID, которые OIDC объявляет как веб-токены JSON, токены доступа не имеют определенного формата. Они не должны быть (и не обязательно) JWT. Однако во многих решениях для идентификации используются JWT как маркеры доступа, поскольку есть готовый формат и он обеспечивает хорошую проверку.
В итоге HireMe123 получает два токена от сервера авторизации MyCalApp: токен идентификации (Token ID) (если проверка пользователя прошла успешна) и токен доступа (Access Token) для доступа к ресурсам конечному пользователю.
Токены доступа прозрачны для клиента
Токены доступа предназначены для API ресурса, и важно, чтобы они были прозрачны для клиента. Зачем?
Токены доступа могут измениться в любое время. У них должно быть короткое время истечения, поэтому пользователь может часто получать новые. Они также могут быть переизданы для доступа к различным API или использования разных разрешений. Клиентское приложение никогда не должно содержать код, который опирается на содержимое токена доступа. Код, который делает это, был бы хрупким и почти гарантированно сломался.
Доступ к ресурсным API
Допустим, мы хотим использовать токен доступа для вызова API из одностраничного приложения. Как это выглядит?
Мы рассмотрели аутентификацию выше, поэтому давайте предположим, что пользователь вошел в наше приложение JS в браузере. Приложение отправляет запрос авторизации на сервер авторизации, запрашивая токен доступа для вызова API.
Затем, когда наше приложение хочет взаимодействовать с API, мы присоединяем токен доступа к заголовку запроса, например, так:
Затем авторизованный запрос отправляется в API, который проверяет токен с помощью промежуточного программного обеспечения middleware. Если все проверено, то API возвращает данные (например, JSON) в приложение, запущенное в браузере.
Это замечательно, но есть кое-что, что может произойти с вами прямо сейчас. Ранее мы заявляли, что OAuth решает проблемы с излишним доступом. Как это решается здесь?
Делегирование со Scopes
Как API узнает, какой уровень доступа он должен предоставить приложению, запрашивающему использование его API? Мы делаем это с помощью scopes.
Scopes (Области действия) «ограничивают возможности приложения от имени пользователя». Они не могут предоставлять привилегии, которых у пользователя еще нет. Например, если у пользователя MyCalApp нет разрешения на создание новых корпоративных учетных записей MyCalApp, scopes, предоставленные HireMe123, также никогда не позволят пользователю создавать новые корпоративные учетные записи.
Scopes делегируют управление доступом к API или ресурсу. Затем API отвечает за объединение входящих scopes с фактическими правами пользователя для принятия соответствующих решений по управлению доступом.
Давайте рассмотрим это на нашем примере.
Я использую приложение HireMe123, и HireMe123 хочет получить доступ к стороннему API MyCalApp для создания событий от моего имени. HireMe123 уже запросил токен доступа для MyCalApp с сервера авторизации MyCalApp. Этот токен содержит некоторую важную информацию, такую как:
HireMe123 отправляет запрос в API MyCalApp с токеном доступа в своем заголовке авторизации. Когда MyCalApp API получает этот запрос, он может увидеть, что токен содержит scope write: events.
Но MyCalApp размещает учетные записи календаря для сотен тысяч пользователей. В дополнение к рассмотрению scope в токене, промежуточному программному обеспечению (middleware) API MyCalApp необходимо проверить sub идентификатор пользователя, чтобы убедиться, что этот запрос от HireMe123 может только использовать мои привилегии для создания событий с моей учетной записью MyCalApp.
В контексте делегированной авторизации scopes (области действия) показывают, что приложение может делать от имени пользователя. Они являются подмножеством общих возможностей пользователя.
Предоставление согласия
Помните, когда сервер авторизации спрашивал пользователя HireMe123 о его согласии разрешить HireMe123 использовать привилегии пользователя для доступа к MyCalApp?
Этот диалог согласия может выглядеть примерно так:
HireMe123 может запросить множество различных областей, например:
В общем, мы должны избегать увеличения количества областей с правами пользователя. Тем не менее, можно добавить разные области для отдельных пользователей, если ваш сервер авторизации обеспечивает управление доступом на основе ролей (Role-Based Access Control — RBAC).
С RBAC вы можете настроить роли пользователей с определенными разрешениями на вашем сервере авторизации. Затем, когда сервер авторизации выдает токены доступа, он может включать роли определенных пользователей в свои области.
Ресурсы и что дальше?
Мы рассмотрели много материала, и даже не приблизились к рассмотрению всему что есть в области аутентификации и авторизации. Я надеюсь, что это была полезная статья по идентификации, авторизации и аутентификации.
В настоящее время я работаю над несколькими дополнительными постами в блоге, в которых более подробно рассматриваются веб-токены JSON, а также аутентификация и авторизация для приложений JavaScript.
Если вы хотите узнать больше, гораздо больше по этим темам, вот несколько полезных ресурсов для вас:
Выучить больше
Серия видеороликов Learn Identity в документах Auth0 — это лекционная часть нового учебного курса по найму для инженеров в Auth0, представленного главным архитектором Витторио Берточчи. Если вы хотите лично узнать, как это делается в Auth0, она абсолютно бесплатна и доступна для всех.
Спецификации OAuth 2.0 и OpenID Connect являются сложными, но как только вы ознакомитесь с терминологией и получите базовые знания об идентификации, они будут полезны, информативны и станут намного более удобочитаемыми. Почитать их можно здесь: The OAuth 2.0 Authorization Framework и OpenID Connect Specifications..
JWT.io — это ресурс о JSON Web Token, который предоставляет инструмент отладчика и каталог библиотек подписи/проверки JWT для различных технологий.
OpenID Connect Playground — это отладчик, который позволяет разработчикам шаг за шагом исследовать и тестировать вызовы и ответы OIDC.
Спасибо!
Если вы хотите пообщаться, я доступен в Твиттере на @KimMaida, и я также выступаю на конференциях и мероприятиях. Я надеюсь увидеть вас когда-нибудь, и большое спасибо за чтение!