Авторизация без регистрации: Авторизация без регистрации

5 решений для удобства авторизации и 16 решений для удобства регистрации — Дизайн на vc.ru

На связи Максим Жуков из KISLOROD. Мы специализируемся на разработке и развитии ecommerce-проектов. Делимся экспертизой в этом блоге и телеграм-канале. Подписывайтесь, чтобы не пропускать материалы о точечном увеличении конверсий в клиентских проектах, исследованиях, гипотезах и наблюдениях.

4351

просмотров

Ранее мы уже рассказали о грамотной реализации:

Сегодня поговорим об авторизации и регистрации в интернет-магазине. От того, насколько удобно для пользователя реализована авторизация и регистрация в интернет-магазине, сильно зависит конверсия. Рассмотрим, как упростить эти процессы для покупателей и не терять их из-за нежелания регистрироваться или авторизоваться.

Значение функционала авторизации и регистрации в интернет-магазине

Ритейлеры заинтересованы в том, чтобы посетители регистрировались на сайте. После регистрации пользователь попадает в подписную базу. Благодаря этому можно:

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

Процесс регистрации улучшает поведенческие факторы — так как пользователь совершает несколько целевых действий и переходов. А это положительно влияет на ранжирование в поисковых системах.

При этом многие пользователи не хотят выполнять лишние действия, связанные с регистрацией и авторизацией в интернет-магазине. И если функционал реализован неграмотно и усложняет процесс покупки, это обязательно скажется на конверсии. Дальнейшие рекомендации помогут сделать авторизацию и регистрацию выгодной для пользователей, а сами процедуры — максимально простыми.

5 возможностей для улучшения функционала авторизации в интернет-магазине

1. Размещайте форму авторизации на сайте в привычном месте

Пользователи привыкли видеть форму в правом верхнем углу. Чтобы им не приходилось искать форму авторизации на сайте, размещайте ее в привычном месте.

2. Упростите авторизацию и регистрацию на сайте

1. Если пользователь ошибся, укажите в чем именно — логине или пароле.
2. Внедрите функционал, позволяющий проверить правильность введения пароля до отправки формы.

3. Позвольте легко получить новый пароль, разместив ссылку на его восстановление рядом с полем пароля — на случай, если пользователь его забыл.

4. Запоминайте, что пользователь вошел в систему (до 7 дней). Чтобы обеспечить безопасность, можно дополнительно запрашивать пароль при вводе данных платежной карты.

Поле с возможностью видеть пароль на ormatek.com

3. Внедрите авторизацию через телефон

Всё меньше пользователей хотят использовать авторизацию через email, отдавая предпочтение авторизации через телефон:

1. Нет необходимости запоминать пароль — можно пройти авторизацию, указав код, который придёт в SMS.
2. В эру соцсетей и мессенджеров пользователи всё реже пользуются почтой для обмена сообщениями.

Важно учитывать эти тенденции, если вы работаете преимущественно в b2c-сегменте.

Единственный недостаток внедрения авторизации через телефон — дополнительные издержки на оплату SMS рассылки.

Авторизация через телефон на ozon.ru

4. Реализуйте авторизацию через социальные сети

Вы также можете внедрить авторизацию через социальные сети. Это упростит пользователям процесс регистрации и авторизации. Статистические исследования показывают, что 53% пользователей авторизуются через Facebook и 44,8% — через Google.

Регистрация через соцсети увеличивает конверсию и позволяет получать реферальный трафик за счет репостов. А еще интернет-магазин получает доступ к персональным данным, благодаря чему можно понять предпочтения пользователей и использовать это для создания рекламных предложений.

Хороший пример формы для авторизации на сайте нашли на lamoda.ru — можно войти и с помощью соцсетей, и стандартным способом.

Авторизация через соцсети и emаil на lamoda. ru

Несколько нюансов авторизации через соцсети:

• способ предпочитает молодая аудитория;
• возможна авторизация через Фейсбук, авторизация на сайте через ВК или даже через Одноклассники — учитывайте предпочтения аудитории и реализуйте сразу все возможности;
• для бизнес-аудитории больше подойдет авторизация на сайте через Google;
• пользователь может забыть, с помощью какой соцсети регистрировался;
• удалив аккаунт в соцсети, пользователь не получит доступ к сайту.

5. Сохраняйте положение пользователя при авторизации

Пользователи могут авторизоваться на разных этапах взаимодействия с интернет-магазином:

После авторизации текущее положение посетителя не должно изменяться, чтобы он мог продолжать путь по воронке продаж.

Особенно важно оставлять пользователя на странице оформления заказа — даже если он сбрасывал пароль. Если покупатель уже оформляет товар, а его перенаправят на главную, это может привести к уходу с сайта. Ведь пользователь мог находиться в карточке товара, который долго искал. А после возвращения на главную у него могут возникнуть сомнения, что он снова найдет карточку — по крайней мере, быстро.

Как сохранить положение пользователя:

• реализовать форму авторизации на сайте в раскрывающемся меню, без перехода на страницу авторизации;
• отображать форму авторизации на сайте во всплывающем поверх текущей страницы в модальном окне.

Большинство интернет-магазинов в Рунете использует второе решение. После такой авторизации можно будет обновить текущую страницу и не потерять положение на сайте.

16 возможностей для улучшения функционала регистрации в интернет-магазине

1. Сделайте регистрацию необязательной

Согласно исследованиям Baymard Institute, 37% пользователей откажутся от оформления заказа из-за необходимости создавать учетную запись. Зачастую пользователям проще сделать заказ в другом интернет-магазине, чем регистрироваться. Есть категория покупателей, которые сознательно выбирают магазины с необязательной регистрацией. Чтобы не терять клиентов, дайте им право выбора — регистрироваться или нет.

2. Расскажите о преимуществах регистрации

Преимущества зависят от возможностей учетной записи конкретного интернет-магазина. Сообщите о них, когда предлагаете зарегистрироваться, чтобы убедить пользователя заполнить форму. Например:

3. Используйте сильные стимулы

Чтобы стимулировать пользователя зарегистрироваться, можно использовать:

• скидку на покупку или подарок;
• бесплатную услугу — например, доставку;
• участие в бонусной программе;
• розыгрыш призов.

При оформлении заказа предлагайте купить товар без регистрации или зарегистрироваться и получить что-то ценное.

Возможность получить бонусы при регистрации на onlinetrade.ru

4. Предложите стать избранным

Вместо обычной регистрации можно предложить пользователям стать участником закрытого клуба. Это работа на уровне психологии — снять предубеждения о регистрации и вызывать желание стать особенным.

Например, на сайте онлайн-винотек Grape можно вступить в закрытый клуб и получить доступ к специальным скидкам и акциям.

Закрытый клуб в онлайн-винотеках Grape на grapewines.ru

5. Покажите, что бонусы за регистрацию — только начало

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

Накопительная бонусная программа для зарегистрированных пользователей на сайте grapewines. ru

6. Минимизируйте количество полей

Форма регистрации на сайте с множеством полей пугают пользователей. Чем меньше полей, тем выше вероятность регистрации. Оставьте только те поля, которые действительно необходимы.

Не заставляйте пользователей вводить пароль в двух полях — можно показывать пароль, который фактически вводит пользователь, чтобы избежать ошибки введения. Запрашивайте дополнительную информацию после регистрации. К такой информации относится, например, фотография или дата рождения пользователя.

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

7. Используйте адрес электронной почты вместо логина

Человек может забыть логин, особенно если использует разные логины на разных сайтах. Но он не забудет адрес своей электронной почты. Еще одно преимущество такого подхода — вы в любом случае запрашивали адрес почты, а значит без логина количество полей в форме уменьшится.

8. Сообщите, если учетная запись занята

Пользователь может забыть, что когда-то уже регистрировался на сайте. Если учетная запись для электронной почты уже существует, то сразу сообщите об этом пользователю — не ждите отправки формы. Предложите ввести пароль для учетной записи и отправить новый пароль на указанную почту.

9. Дайте понять, какие поля обязательны для заполнения

Если в форме есть обязательные и необязательные для заполнения поля, сообщите об этом пользователю. Не отмечайте только необязательные или только обязательные поля. Ставьте метки возле каждого поля.

В исследовании Baymard Institute 32% пользователей не заполняли часть обязательных полей в формах, в которых были отмечены только необязательные поля. Пользователям не очевидно значение отсутствия маркировки поля. И вместо того, чтобы заполнять поля без маркировки, пользователи тратят время на раздумья, обязательны ли они. Отсутствие пометки «обязательное поле» увеличивает время заполнения формы и количество ошибок

Формы, в которых были отмечены только обязательные поля, показали лучшие результаты при тестировании. Правда, показатель заполнения необязательных полей был почти идентичен показателю заполнения обязательных полей. То есть пользователи думали, что необязательное поле обязательно к заполнению. И в некоторых случаях испытывали дискомфорт, так как считали, что обязаны предоставить информацию, которую не хотели бы раскрывать (например, должность). Такая ситуация может привести к отказу от регистрации. Избавляйтесь от ненужных полей.

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

10. Не предъявляйте слишком строгие требования к паролю

Чрезмерно строгие требования к паролям могут стать серьезным препятствием к авторизации во время оформления заказа.

По данным Baymard Institute,18,75% пользователей, которые делают покупку на сайте повторно, не завершают заказ из-за того, что не могут вспомнить сложный пароль. Обычно они пробуют несколько комбинаций, затем сбрасывают пароль и ждут письма с возможностью поменять его. На этом этапе могут возникнуть проблемы — задержка письма, попадание в спам — вероятность отказа от покупки очень высока.

У новых пользователей необходимость придумывать сложный пароль вызывает негативные эмоции в процессе регистрации. Правда, если сообщать требования к паролю заранее, посетители редко отказываются от создания учетной записи по этой причине. Если у вас есть требования к паролю, укажите их прямо в форме регистрации на сайте или хотя бы тогда, когда пользователь получит сведения об ошибке при вводе будущего пароля.

Отображение требований к паролю на aliexpress.ru

У посетителей обычно есть несколько привычных паролей, которые они используют на разных сайтах. Если пароль слишком простой, сообщите пользователю об этом и предложите создать более надежный пароль. Но не ограничивайте возможность использовать привычный пароль.

Интернет-магазин заинтересован не только в защите информации, но и в упрощении входа для пользователей. Исследователи из Baymard рекомендуют использовать минимальные требования к паролю — 6 строчных букв. Чтобы это не отразилось негативно на безопасности учетной записи, можно внедрить дополнительные меры безопасности. Например, необходимость каждый раз вводить данные платежной карты при оплате. При этом не стоит ограничивать максимальную длину и сложность пароля, так как есть пользователи, которые предпочитают перестраховаться.

11. Используйте фоновую регистрацию

Перед покупкой у пользователя есть выбор — зарегистрироваться или купить без регистрации. Но при оформлении заказа он все равно вводит данные, необходимые для регистрации. А значит, можно зарегистрировать пользователя самостоятельно. После оформления заказа пользователь получит письмо с регистрационными данными на электронную почту.

12. Не используйте капчу

Исследователи из Baymard Institute не рекомендуют использовать капчу — даже при условии хорошей реализации она приводит к потере покупателей. Если же капча настолько нечитаема, как в примере ниже, вероятность отказа очень высока.

Плохой пример реализации капчи на citilink.ru

По результатам исследований, около 8,66% всех пользователей ошибаются при первой попытке. Если капча чувствительна к регистру, ошибутся 29,45%. Только 66% с первой попытки правильно ввели капчу. Если пользователи неправильно введут капчу два раза подряд, то скорее всего покинут сайт.

Если без капчи не обойтись, опирайтесь на следующие правила:

• используйте читаемые символы;
• не учитывайте разницу в заглавных и строчных буквах;
• не удаляйте содержание полей, если капча введена неправильно, чтобы пользователю не пришлось снова вносить все данные;
• просите вводить капчу только один раз за сеанс, если пользователь ввел ее правильно, но ошибся в чем-то другом.

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

Пример использование сервиса reCAPTCHA на askona.ru

13. Не блокируйте учетную запись при неправильном введении пароля

Блокировка учетной записи при многократном неправильном введении пароля более агрессивная мера безопасности, чем капча. Она приводит к еще большему количеству отказов пользователей.

Как уже писали выше, если пользователям приходится использовать сложные пароли вместо стандартных, они часто забывают их. Поэтому начинают пробовать разные комбинации, что вызывает блокировку учетной записи. А это, в свою очередь приводит к почти стопроцентной вероятности отказа от покупки. Вряд ли кто-то будет ждать отмены блокировки — скорее уйдет покупать товар в другом месте.

14. Не очищайте данные формы при ошибке

Не удаляйте все введенные пользователем данные при одной ошибке — не заставляйте вводить все заново.

15. Не требуйте активации учетной записи

Необходимость открыть электронное письмо с активацией учетной записи и перейти по ссылке добавляет действий в процесс регистрации. Дайте доступ к возможностям зарегистрированного пользователя сразу после регистрации.

16. Сделайте так, чтобы пользователь легко мог найти приветственное письмо

Когда пользователь забывает пароль, то зачастую пытается найти письмо с паролем. Облегчите задачу, отразив суть письма в теме. Вместо «Поздравляем!» или «Добро пожаловать!» используйте тему вроде «Данные учетной записи в таком-то интернет-магазине». В качестве отправителя также должно быть название ресурса.

Заключение

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

Чтобы оценить, насколько грамотно в вашем проекте реализованы другие элементы интерфейса, скачайте наш внутренний чек-лист для улучшения юзабилити интернет-магазина с 250+ пунктами.

В следующий раз обсудим нюансы реализации личного кабинета в интернет-магазине. Подпишитесь на этот блог или наш телеграм-канал, чтобы не пропустить статью.

И не забудьте поставить лайк (+1), если понравился материал.

Аутентификация пользователя без регистрации — в массы / Хабр

В своей статье я хочу обсудить способ аутентификации посетителей небольшого сайта без каких-либо усилий с их стороны. Далее посетителем я буду называть человека, сидящего по ту сторону HTTP-соединения. Клиентом будем называть его браузер. Возможно, описанный метод уже где-то широко используется, и я буду благодарен тому, кто расскажет мне об этом.

Предположим, что у нас есть некоторый сайт и для сайта поставлена задача отличать пользователей одного от другого. При этом нам известны два факта: «посетитель сайта ленив» и «посетитель сайта пуглив». Это значит, что ему лень заполнять даже форму OpenID, а уж регистрироваться он не будет и подавно. Немного поразмыслив, приходим к выводу, что без регистрации (в той или иной мере) мы не сможем отличить одного посетителя от другого, но мы сможем различить два разных клиента (например, оставив какую-нибудь печеньку-долгожителя). Таким образом, каждый клиент для нас становится уникальным — без каких-либо усилий со стороны посетителя. Неплохо.

Сразу же заметны два минуса: один и тот же посетитель должен каким-либо образом «склеить» два аккаунта, чтобы идентифицировать себя однозначно на разных клиентах; посетитель лишается такого привычного понятия, как логин. Если первое можно реализовать технически (предположу, что «склеивать» аккаунты будут не все посетители, а хотя бы один из пяти), то со вторым могут возникнуть трудности скорее психологического характера: как мы будем визуально различать одного посетителя от другого? Присваивать десятизначное число некрасиво, выдавать картинку а-ля Хабрахабр тоже для постоянного пользования не всем удобно.

Наверное, с этим вопросом каждый должен разобраться самостоятельно, ориентируясь на специфику своего проекта. На моем сайте я, например, генерирую случайную пару Имя Отчество. Учитывая, что у меня в базе около 130 имен (из них 80 сгодятся под отчество), я получаю неплохой набор уникальных имен для своих посетителей. В нашем обществе обращаться к незнакомому человеку по имени-отчеству считается нормальным, потому проблем быть не должно. В базе, конечно, я посетителей различаю по id.

Таким образом, мы получаем возможность идентифицировать посетителя самостоятельно. Если для больших проектов такой способ слишком неудобен, то для маленьких сайтов вроде блогов на WordPress подобный вариант вполне сгодится, ведь мы получаем два очевидных плюса: убираем анонимусов и позволяем посетителям пользоваться почти всеми благами зарегистрированных пользователей. Ведь все знают, что главное — зацепить посетителя информацией, а он, благодарный, потом и сам зарегистрируется везде, где попросят. А для начала получаем такой себе маскарад, если хотите.

Требования аутентификации и авторизации API

Edit me

Прежде чем пользователи смогут отправлять запросы с помощью 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, чтобы использовать API. Ключ API представляет собой длинную строку, которую обычно включают либо в URL запроса, либо в заголовок запроса. Ключ API в основном служит способом идентификации лица, выполняющего запрос API (аутентифицируя для использования API). Ключ API также может быть связан с конкретным приложением, которое регистрируется.

Ключи APK используют строку в свойстве заголовка для авторизации запросов

API могут дать как открытый, так и закрытый ключ. Открытый ключ обычно включается в запрос, в то время как закрытый ключ рассматривается скорее как пароль и используется только при обмене данными между серверами. На некоторых сайтах документации API, при заходе на сайт, ключ API автоматически заполняется в примере кода и API Explorer.

Basic Auth

Другой тип авторизации называется Basic Auth. С помощью этого метода отправитель помещает пару имя пользователя:пароль в заголовок запроса. Имя пользователя и пароль кодируются с помощью Base64, который представляет собой метод кодирования, который преобразует имя пользователя и пароль в набор из 64 символов для обеспечения безопасной передачи. Вот пример Basic Auth в заголовке запроса:

Authorization: Basic bG9sOnNlY3VyZQ==

API, использующие Basic Auth, также будут использовать HTTPS, что означает, что содержимое сообщения будет зашифровано в транспортном протоколе HTTP. (Без HTTPS людям было бы легко расшифровать зашифрованные данные)

Когда сервер API получает сообщение, он дешифрует сообщение и проверяет заголовок. После декодирования строки и анализа имени пользователя и пароля он решает, принять или отклонить запрос.

В Postman можно настроить базовую авторизацию, щелкнув вкладку Authorization, выбрав Basic Auth в раскрывающемся списке и введя имя пользователя и пароль справа от двоеточия в каждой строке. На вкладке Заголовки будет показана пара ключ-значение, выглядящая следующим образом:

Authorization: Basic RnJlZDpteXBhc3N3b3Jk

Postman обрабатывает кодировку Base64 автоматически, при вводе имени пользователя и пароля с выбранным Basic Auth.

HMAC (код авторизации сообщений на основе хэша)

HMAC расшифровывается как Hash-based message authorization code — код авторизации сообщений на основе хэша и является более строгим типом аутентификации, более распространенным в финансовых API. В HMAC только отправитель, и получатель знают секретный ключ, который больше неизвестен никому. Отправитель создает сообщение на основе некоторых системных свойств (например, отметка времени запроса плюс идентификатор учетной записи).

Затем сообщение кодируется секретным ключом и проходит через алгоритм безопасного хеширования (SHA — secure hashing algorithm). (Хеш — это зашифрованная строка на основе алгоритма.) Результирующее значение, называемое сигнатурой, помещается в заголовок запроса.

Сервер API (получатель), получая запрос, принимает те же системные свойства (отметка времени запроса плюс идентификатор учетной записи) и использует секретный ключ (который известен только запрашивающей стороне и серверу API) и SHA для генерации одной и той же строки. Если строка соответствует подписи в заголовке запроса, запрос принимается. Если строки не совпадают, запрос отклоняется.

Вот диаграмма, отображающая процесс авторизации HMAC:

Важным моментом является то, что секретный ключ (критический для восстановления хэша) известен только отправителю и получателю. Секретный ключ не включается в запрос. Безопасность HMAC используется, когда нужно убедиться, что запрос является подлинным и не может быть подделан.

OAuth 2.0

Одним из популярных методов аутентификации и авторизации пользователей является OAuth 2.0. Такой подход опирается на сервер аутентификации для связи с сервером API для предоставления доступа. Понять, что используется метод OAuth 2.0, можно когда предлагается войти в систему при помощи сторонних сервисов, как Twitter, Google или Facebook.

окно входа в систему, использующую Oauth3.0

Существует несколько разновидностей OAuth, а именно «one-legged OAuth» и «three-legged OAuth». One-legged OAuth используется, когда нет конфиденциальных данных для защиты. Например, в том случае, если просто получаем общую информацию только для чтения.

Three-legged OAuth используется, когда нужно защитить конфиденциальные данные. В этом сценарии взаимодействуют три группы:

• сервер аутентификации;
• сервер API;
• пользователь или приложение.

Вот базовый процесс Oauth3.0:

Сначала пользовательское приложение отправляет ключ приложения и секретные данные на страницу входа в систему на сервере аутентификации. Если аутентификация пройдена, сервер аутентификации возвращает пользователю токен доступа (авторизации).

Токен доступа (авторизации) упакован в параметр запроса в перенаправлении ответа (302) на запрос. Перенаправление направляет запрос пользователя обратно на сервер ресурсов (сервер API).

Затем пользователь отправляет запрос на сервер ресурсов (сервер API). Токен доступа (авторизации) добавляется в заголовок запроса API со словом Bearer, за которым следует строка токена. Сервер API проверяет токен доступа (авторизации) в запросе пользователя и решает, аутентифицировать ли пользователя.

Токены доступа (авторизации) не только обеспечивают аутентификацию для запрашивающей стороны, но и определяют права пользователя на использование API. Кроме того, токены доступа (авторизации) обычно истекают через некоторое время и требуют от пользователя повторного входа в систему. Для получения дополнительной информации об OAuth 2.0 можно посмотреть ресурсы:

Что документируется в разделе аутентификации

В документации API не нужно подробно объяснять внешним пользователям, как работает аутентификация. Отсутствие объяснений внутренних процессов аутентификации, является лучшей практикой, поскольку хакерам будет сложнее злоупотреблять API.

Тем не менее нужно объяснить необходимую информацию:

• как получить API ключ;
• как пройти аутентификацию запроса;
• сообщения об ошибках, связанных с неверной аутентификацией;
• чувствительность информации аутентификации;
• период действия токена доступа (авторизации).

Если есть открытый и закрытый ключи, нужно объяснить, где следует использовать каждый ключ, и отметить, что закрытые ключи не должны использоваться совместно. Если разные уровни лицензий предоставляют разный доступ к вызовам API, эти уровни лицензирования должны быть явно указаны в разделе авторизации или в другом месте.

Поскольку раздел API ключей важен, и нужен разработчикам до того, как они начнут использовать API, этот раздел должен быть в начале руководства.

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

API ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

Twitter

авторизация Twitter

В Twitter подробный пример оправдан и предоставлен, поскольку требования к авторизации OAuth 2.0 немного сложнее.

Amazon Web Services

авторизация Amazon

Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.

Dropbox

Авторизация в Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

👨‍💻 Практическое занятие: Авторизация

В своем найденном опен-сорс проекте найдем информацию об авторизации для запросов к API. Ответьте на следующие вопросы:

• Какого рода авторизация требуется для отправки запросов к API?
• Существуют ли разные уровни доступа в рамках авторизации (например, платные и бесплатные), которые определяют, сколько запросов можно сделать или какие типы информации можно получить?
• Можно ли вы получить ключ API или какой-либо другой метод авторизации, необходимый для выполнения тестовых вызовов API?
• Как информация об авторизации интегрируется в раздел “Начало работы”?

🔙

Go next ➡

Чем отличаются друг от друга идентификация, аутентификация и авторизация

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

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

Идентификация, аутентификация и авторизация: серьезные определения

Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:

• Идентификация — процедура, в результате выполнения которой для субъекта идентификации выявляется его идентификатор, однозначно определяющий этого субъекта в информационной системе.
• Аутентификация — процедура проверки подлинности, например проверка подлинности пользователя путем сравнения введенного им пароля с паролем, сохраненным в базе данных.
• Авторизация — предоставление определенному лицу или группе лиц прав на выполнение определенных действий.

Объясняем идентификацию, аутентификацию и авторизацию на енотах

Выше было очень много умных слов, теперь давайте упростим до конкретных примеров. Скажем, пользователь хочет войти в свой аккаунт Google. Google подходит лучше всего, потому что там процедура входа явным образом разбита на несколько простейших этапов. Вот что при этом происходит:

• Для начала система запрашивает логин, пользователь его указывает, система распознает его как существующий — это идентификация.
• После этого Google просит ввести пароль, пользователь его вводит, и система соглашается, что пользователь, похоже, действительно настоящий, раз пароль совпал, — это аутентификация.
• Скорее всего, Google дополнительно спросит еще и одноразовый код из SMS или приложения. Если пользователь и его правильно введет, то система окончательно согласится с тем, что он настоящий владелец аккаунта, — это двухфакторная аутентификация.
• После этого система предоставит пользователю право читать письма в его почтовом ящике и все в таком духе — это авторизация.

Аутентификация без предварительной идентификации лишена смысла — пока система не поймет, подлинность чего же надо проверять, совершенно бессмысленно начинать проверку. Для начала надо представиться.

Идентификация без аутентификации — это просто глупо. Потому что мало ли кто ввел существующий в системе логин! Системе обязательно надо удостовериться, что этот кто-то знает еще и пароль. Но пароль могли подсмотреть или подобрать, поэтому лучше подстраховаться и спросить что-то дополнительное, что может быть известно только данному пользователю: например, одноразовый код для подтверждения входа.

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

А вот если бы вы открыли этот документ для чтения только определенным пользователям, то еноту в таком случае сперва пришлось бы идентифицироваться (ввести свой логин), потом аутентифицироваться (ввести пароль и одноразовый код) и только потом получить право на чтение документа — авторизоваться.

А уж если речь идет о содержимом вашего почтового ящика, то Google никогда и ни за что не авторизует неопознанного енота на чтение вашей переписки — если, конечно, он не идентифицируется с вашим логином и не аутентифицируется с вашим паролем. Но тогда это уже не будет неопознанный енот, поскольку Google однозначно определит этого енота как вас.

Теперь вы знаете, чем идентификация отличается от аутентификации и авторизации. Что еще важно понимать: аутентификация — пожалуй, самый важный из этих процессов с точки зрения безопасности вашего аккаунта. Если вы ленитесь и используете для аутентификации только слабенький пароль, то какой-нибудь енот может ваш аккаунт угнать. Поэтому:

• Придумывайте для всех аккаунтов надежные и уникальные пароли.
• Если испытываете трудности с их запоминанием — вам всегда придет на помощь менеджер паролей. Он же поможет их сгенерировать.
• Обязательно включайте двухфакторную аутентификацию — одноразовые коды в SMS или приложении — во всех сервисах, которые это позволяют. Иначе какой-нибудь неопознанный енот, так или иначе заполучивший ваш пароль, сможет прочитать вашу тайную переписку или сделать что-то еще более неприятное.

Руководство Django Часть 8: Аутентификация и авторизация пользователя — Изучение веб-разработки

В данном руководстве мы продемонстрируем вам систему входа пользователя на ваш сайт используя его собственный аккаунт. Кроме того, мы покажем как реализовать  контроль того, что может видеть и делать пользователь, в зависимости от того, залогинен он, или нет, а также имеет ли он соответствующий уровень прав доступа (permissions). Для того чтобы продемонстрировать все это, мы расширим LocalLibrary, добавив страницы для входа/выхода, а также страницы просмотра/редактирования книг, специфические для пользователя и персонала.

Django предоставляет систему аутентификации и авторизации («permission») пользователя, реализованную на основе фреймворка работы с сессиями, который мы рассматривали в предыдущей части. Система аутентификации и авторизации позволяет вам проверять учётные данные пользователей и определять какие действия какой пользователь может выполнять. Данный фреймворк включает в себя встроенные модели для Пользователей и Групп (основной способ применения прав доступа для более чем одного пользователя), непосредственно саму систему прав доступа (permissions)/флаги, которые определяют может ли пользователь выполнить задачу, с какой формой и отображением для авторизованных пользователей, а так же получить доступ к контенту с ограниченным доступом.

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

В данном разделе руководства мы покажем вам реализацию аутентификации пользователя на сайте LocalLibrary, создание страниц входа/выхода, добавления разграничения доступа (permissions) к вашим моделям, а также продемонстрируем контроль за доступом к некоторым страницам. Мы будем использовать аутентификацию/авторизацию для показа пользователям и сотрудникам библиотеки, списков книг, которые были взяты на прокат.

Система аутентификации является очень гибкой и позволяет вам формировать свои собственные URL-адреса, формы, отображения, а также шаблоны страниц, если вы пожелаете, с нуля, через простой вызов функций соответствующего API для авторизации пользователя. Тем не менее, в данной статье мы будем использовать «встроенные» в Django методы отображений и форм аутентификации, а также методы построения страниц входа и выхода. Нам все ещё необходимо создавать шаблоны страниц, но это будет достаточно несложно.

Мы покажем вам как реализовать разграничение доступа (permissions), а также выполнять соответствующую проверку статусов авторизации и прав доступа, в отображениях, и в шаблонах страниц.

Аутентификация была подключена автоматически когда мы создали скелет сайта (в части 2), таким образом на данный момент вам ничего не надо делать.

Примечание: Необходимые настройки были выполнены для нас, когда мы создали приложение при помощи команды django-admin startproject. Таблицы базы данных для пользователей и модели авторизации были созданы, когда в первый раз выполнили команду python manage.py migrate.

Соответствующие настройки сделаны в параметрах INSTALLED_APPS и MIDDLEWARE файла проекта (locallibrary/locallibrary/settings.py), как показано ниже:

INSTALLED_APPS = [
    ...
    'django.contrib.auth',  
    'django.contrib.contenttypes',  
    ....

MIDDLEWARE = [
    ...
    'django.contrib.sessions.middleware.SessionMiddleware',  
    ...
    'django.contrib.auth.middleware.AuthenticationMiddleware',  
    ....

Вы уже создали своего первого пользователя когда мы рассматривали Административная панель сайта Django в части 4 (это был суперпользователь, созданный при помощи команды python manage.py createsuperuser). Наш суперпользователь уже авторизован и имеет все необходимые уровни доступа к данным и функциям, таким образом нам необходимо создать тестового пользователя для отработки соответствующей работы сайта. В качестве наиболее быстрого способа, мы будем использовать административную панель сайта для создания соответствующих групп и аккаунтов locallibrary.

Примечание: вы можете создавать пользователей программно, как показано ниже. Например, вам мог бы подойти данный способ в том случае, если вы разрабатываете интерфейс, который позволяет пользователям создавать их собственные аккаунты (вы не должны предоставлять доступ пользователям к административной панели вашего сайта).

from django.contrib.auth.models import User


user = User.objects.create_user('myusername', '[email protected]', 'mypassword')


user.first_name = 'John'
user.last_name = 'Citizen'
user.save()

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

Запустите сервер разработки и перейдите к административной панели вашего сайта (http://127.0.0.1:8000/admin/). Залогиньтесь на сайте при помощи параметров (имя пользователя и пароля) аккаунта суперпользователя. Самая «верхняя» страница панели Администратора показывает все наши модели. Для того, чтобы увидеть записи в разделе Authentication and Authorisation вы можете нажать на ссылку Users, или Groups.

В первую очередь, в качестве нового члена нашего сайта, давайте создадим новую группу.

1. Нажмите на кнопку Add (Добавить) (рядом с Group) и создайте новую группу; для данной группы введите Name (Имя) «Library Members».
2. Для данной группы не нужны какие-либо разрешения, поэтому мы просто нажимаем кнопку SAVE (Сохранить) (вы перейдёте к списку групп).

Теперь давайте создадим пользователя:

1. Перейдите обратно на домашнюю страницу административной панели
2. Для перехода к диалогу добавления пользователя нажмите на кнопку Add, соответствующую строке Users (Пользователи).
3. Введите соответствующие Username (имя пользователя) и Password/Password confirmation (пароль/подтверждение пароля) для вашего тестового пользователя
4. Нажмите SAVE для завершения процесса создания пользователя.

   Административная часть сайта создаст нового пользователя и немедленно перенаправит вас на страницу Change user (Изменение параметров пользователя) где вы можете, соответственно, изменить ваш username, а кроме того добавить информацию для дополнительных полей модели User. Эти поля включают в себя имя пользователя, фамилию, адрес электронной почты, статус пользователя, а также соответствующие параметры доступа (может быть установлен только флаг  Active). Ниже вы можете определить группу для пользователя и необходимые параметры доступа, а кроме того, вы можете увидеть важные даты, относящиеся к пользователю (дату подключения к сайту и дату последнего входа).

5. В разделе Groups, из списка Доступные группы выберите группу Library Member, а затем переместите её в блок «Выбранные группы» (нажмите стрелку-«направо», находящуюся между блоками).
6. Больше нам не нужно здесь нечего делать, просто нажмите «Save»(Сохранить), и вы вернётесь к списку созданных пользователей.

Вот и все! Теперь у вас есть учётная запись «обычного члена библиотеки», которую вы сможете использовать для тестирования (как только добавим страницы, чтобы пользователи могли войти в систему).

Note: Попробуйте создать другого пользователя, например «Библиотекаря». Так же создайте группу «Библиотекарей» и добавьте туда своего только что созданного библиотекаря

Django предоставляет почти все, что нужно для создания страниц аутентификации входа, выхода из системы и управления паролями из коробки. Это включает в себя url-адреса, представления (views) и формы,но не включает шаблоны — мы должны создать свой собственный шаблон!

В этом разделе мы покажем, как интегрировать систему по умолчанию в Сайт LocalLibrary и создать шаблоны.  Мы поместим их в основные URL проекта.

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

Примечание: В этом случае мы могли бы разумно поместить страницы аутентификации, включая URL-адреса и шаблоны, в наше приложение каталога. Однако, если бы у нас было несколько приложений, было бы лучше отделить это общее поведение входа в систему и иметь его доступным на всем сайте, так что это то, что мы показали здесь!

Проектирование URLs

Добавьте следующее в нижней части проекта urls.py файл (locallibrary/locallibrary/urls.py) файл:

urlpatterns += [
    path('accounts/', include('django.contrib.auth.urls')),
]

Перейдите по http://127.0.0.1:8000/accounts/ URL (обратите внимание на косую черту!), Django покажет ошибку, что он не смог найти этот URL, и перечислить все URL, которые он пытался открыть. Из этого вы можете увидеть URL-адреса, которые будут работать, например:

Примечание. Использование вышеуказанного метода добавляет следующие URL-адреса с именами в квадратных скобках, которые могут использоваться для изменения сопоставлений URL-адресов. Вам не нужно реализовывать что-либо ещё — приведённое выше сопоставление URL-адресов автоматически отображает указанные ниже URL-адреса.

accounts/ login/ [name='login']
accounts/ logout/ [name='logout']
accounts/ password_change/ [name='password_change']
accounts/ password_change/done/ [name='password_change_done']
accounts/ password_reset/ [name='password_reset']
accounts/ password_reset/done/ [name='password_reset_done']
accounts/ reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/ reset/done/ [name='password_reset_complete']

Теперь попробуйте перейти к URL-адресу входа (http://127.0.0.1:8000/accounts/login/). Это приведёт к сбою снова, но с ошибкой, сообщающей вам, что нам не хватает требуемого шаблона (registration / login.html) в пути поиска шаблона. Вы увидите следующие строки, перечисленные в жёлтом разделе вверху:

Exception Type:    TemplateDoesNotExist
Exception Value:    registration/login.html

Следующий шаг — создать каталог регистрации в пути поиска, а затем добавить файл login.html.

Каталог шаблонов

URL-адреса (и неявные представления), которые мы только что добавили, ожидают найти связанные с ними шаблоны в каталоге / регистрации / где-то в пути поиска шаблонов.

Для этого сайта мы разместим наши HTML-страницы в каталоге templates / registration /. Этот каталог должен находиться в корневом каталоге проекта, то есть в том же каталоге, что и в каталоге и папках locallibrary). Создайте эти папки сейчас.

Примечание: ваша структура папок теперь должна выглядеть как показано внизу:
locallibrary (django project folder)
   |_catalog
   |_locallibrary
   |_templates (new)
                |_registration

Чтобы сделать эти директории видимыми для загрузчика шаблонов   (т. е. помещать этот каталог в путь поиска шаблона) откройте настройки проекта (/locallibrary/locallibrary/settings.py), и обновите в секции TEMPLATES строку 'DIRS' как показано.

TEMPLATES = [
    {
        ...
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        ...

Шаблон аутентификации

Важно: Шаблоны аутентификации, представленные в этой статье, являются очень простой / слегка изменённой версией шаблонов логина демонстрации Django. Возможно, вам придётся настроить их для собственного использования!

Создайте новый HTML файл, названный /locallibrary/templates/registration/login.html. дайте ему следующее содержание:

{% extends "base_generic.html" %}

{% block content %}

{% if form.errors %}
  <p>Your username and password didn't match. Please try again.</p>
{% endif %}

{% if next %}
  {% if user.is_authenticated %}
    <p>Your account doesn't have access to this page. To proceed,
    please login with an account that has access.</p>
  {% else %}
    <p>Please login to see this page.</p>
  {% endif %}
{% endif %}

<form method="post" action="{% url 'login' %}">
{% csrf_token %}
<table>

<tr>
  <td>{{ form.username.label_tag }}</td>
  <td>{{ form.username }}</td>
</tr>

<tr>
  <td>{{ form.password.label_tag }}</td>
  <td>{{ form.password }}</td>
</tr>
</table>

<input type="submit" value="login" />
<input type="hidden" name="next" value="{{ next }}" />
</form>

{# Assumes you setup the password_reset view in your URLconf #}
<p><a href="{% url 'password_reset' %}">Lost password?</a></p>

{% endblock %}

Этот шаблон имеет сходство с тем, что мы видели раньше — он расширяет наш базовый шаблон и переопределяет блок контента. Остальная часть кода — это довольно стандартный код обработки формы, о котором мы поговорим в следующем учебном пособии. Все, что вам нужно знать, это показ формы, в которой вы можете ввести своё имя пользователя и пароль, а если вы введёте недопустимые значения, вам будет предложено ввести правильные значения, когда страница обновится.

Перейдите на страницу входа (http://127.0.0.1:8000/accounts/login/) когда вы сохраните свой шаблон, и вы должны увидеть что-то наподобие этого:

Если ваша попытка войти в систему будет успешной,  вы будете перенаправлены на другую страницу (по умолчанию это будет http://127.0.0.1:8000/accounts/profile/). Проблема здесь в том, что по умолчанию Django ожидает, что после входа в систему вы захотите перейти на страницу профиля, что может быть или не быть. Поскольку вы ещё не определили эту страницу, вы получите ещё одну ошибку!

Откройте настройки проекта (/locallibrary/locallibrary/settings.py) и добавьте текст ниже. Теперь, когда вы входите в систему, вы по умолчанию должны перенаправляться на домашнюю страницу сайта.

LOGIN_REDIRECT_URL = '/'

Шаблон выхода

Если вы перейдёте по URL-адресу выхода (http://127.0.0.1:8000/accounts/logout/), то увидите странное поведение — ваш пользователь наверняка выйдет из системы, но вы попадёте на страницу выхода администратора. Это не то, что вам нужно, хотя бы потому, что ссылка для входа на этой странице приведёт вас к экрану входа в систему администратора. (и это доступно только для пользователей, у которых есть разрешение is_staff).

Создайте и откройте /locallibrary/templates/registration/logged_out.html. Скопируйте текст ниже:

{% extends "base_generic.html" %}

{% block content %}
<p>Logged out!</p>

<a href="{% url 'login'%}">Click here to login again.</a>
{% endblock %}

Этот шаблон очень прост. Он просто отображает сообщение, информирующее вас о том, что вы вышли из системы, и предоставляет ссылку, которую вы можете нажать, чтобы вернуться на экран входа в систему. Если вы снова перейдёте на страницу выхода из системы, вы увидите эту страницу:

Шаблон сброса пароля

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

В качестве отправной точки можно использовать следующие шаблоны.

Форма сброса пароля

Это форма, используемая для получения адреса электронной почты пользователя (для отправки пароля для сброса пароля). Создайте /locallibrary/templates/registration/password_reset_form.html и дайте ему следующее содержание:

{% extends "base_generic.html" %}
{% block content %}

<form action="" method="post">{% csrf_token %}
    {% if form.email.errors %} {{ form.email.errors }} {% endif %}
        <p>{{ form.email }}</p>
    <input type="submit" value="Reset password" />
</form>

{% endblock %}

Сброс пароля

Эта форма отображается после того, как ваш адрес электронной почты будет собран. Создайте /locallibrary/templates/registration/password_reset_done.html, и дайте ему следующее содержание:

{% extends "base_generic.html" %}
{% block content %}
<p>We've emailed you instructions for setting your password. If they haven't arrived in a few minutes, check your spam folder.</p>
{% endblock %}

Сброс пароля по email

Этот шаблон предоставляет текст электронной почты HTML, содержащий ссылку на сброс, которую мы отправим пользователям. Создайте /locallibrary/templates/registration/password_reset_email.html и дайте ему следующее содержание:

Someone asked for password reset for email {{ email }}. Follow the link below:
{{ protocol}}://{{ domain }}{% url 'password_reset_confirm' uidb64=uid token=token %}

Подтверждение на сброс пароля

На этой странице вы вводите новый пароль после нажатия ссылки в электронном письме с возвратом пароля. Создайте /locallibrary/templates/registration/password_reset_confirm.html и дайте ему следующее содержание:

{% extends "base_generic.html" %}

{% block content %}

    {% if validlink %}
        <p>Please enter (and confirm) your new password.</p>
        <form action="" method="post">
            {% csrf_token %}
            <table>
                <tr>
                    <td>{{ form.new_password1.errors }}
                        <label for="id_new_password1">New password:</label></td>
                    <td>{{ form.new_password1 }}</td>
                </tr>
                <tr>
                    <td>{{ form.new_password2.errors }}
                        <label for="id_new_password2">Confirm password:</label></td>
                    <td>{{ form.new_password2 }}</td>
                </tr>
                <tr>
                    <td></td>
                    <td><input type="submit" value="Change my password" /></td>
                </tr>
            </table>
        </form>
    {% else %}
        <h2>Password reset failed</h2>
        <p>The password reset link was invalid, possibly because it has already been used. Please request a new password reset.</p>
    {% endif %}

{% endblock %}

Сброс пароля завершён

Это последний шаблон сброса пароля, который отображается, чтобы уведомить вас о завершении сброса пароля. Создайте /locallibrary/templates/registration/password_reset_complete.html и дайте ему следующее содержание:

{% extends "base_generic.html" %}
{% block content %}

<h2>The password has been changed!</h2>
<p><a href="{% url 'login' %}">log in again?</a></p>

{% endblock %}

Тестирование новых страниц аутентификации

Теперь, когда вы добавили конфигурацию URL и создали все эти шаблоны, теперь страницы аутентификации должны работать! Вы можете протестировать новые страницы аутентификации, попытавшись войти в систему, а затем выйдите из учётной записи суперпользователя, используя эти URL-адреса:

Вы сможете проверить функцию сброса пароля по ссылке на странице входа. Имейте в виду, что Django отправляет только сбросные электронные письма на адреса (пользователи), которые уже хранятся в его базе данных!

Примечание: Система сброса пароля требует, чтобы ваш сайт поддерживал электронную почту, что выходит за рамки этой статьи, поэтому эта часть ещё не будет работать. Чтобы разрешить тестирование, поместите следующую строку в конец файла settings.py. Это регистрирует любые письма, отправленные на консоль (чтобы вы могли скопировать ссылку на сброс пароля с консоли).

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

Для получения дополнительной информации см. Отправка email (Django docs).

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

Тестирование в шаблонах

Вы можете получить информацию о текущем зарегистрированном пользователе в шаблонах с переменной шаблона {{user}} (это добавляется в контекст шаблона по умолчанию при настройке проекта, как и в нашем скелете).

Обычно вы сначала проверяете переменную шаблона {{user.is_authenticated}}, чтобы определить, имеет ли пользователь право видеть конкретный контент. Чтобы продемонстрировать это, мы обновим нашу боковую панель, чтобы отобразить ссылку «Вход», если пользователь вышел из системы, и ссылку «Выход», если он вошёл в систему.

Откройте базовый шаблон (/locallibrary/catalog/templates/base_generic.html) и скопируйте следующий текст в sidebar блок непосредственно перед тегом шаблона endblock.

  <ul>

    ...

   {% if user.is_authenticated %}
     <li>User: {{ user.get_username }}</li>
     <li><a href="{% url 'logout'%}?next={{request.path}}">Logout</a></li>
   {% else %}
     <li><a href="{% url 'login'%}?next={{request.path}}">Login</a></li>
   {% endif %} 
  </ul>

Как вы можете видеть, мы используем теги шаблона if-else-endif для условного отображения текста на основе того, является ли {{user.is_authenticated}} истинным. Если пользователь аутентифицирован, мы знаем, что у нас есть действительный пользователь, поэтому мы вызываем {{user.get_username}}, чтобы отобразить их имя.

Мы создаём URL-адрес для входа и выхода из системы, используя тег шаблона URL-адреса и имена соответствующих конфигураций URLs. Также обратите внимание на то, как мы добавили ?next={{request.path}} в конец URLs. Это означает, что следующий URL-адрес содержит адрес (URL) текущей страницы, в конце связанного URL-адреса. После того, как пользователь успешно выполнил вход в систему, представления будут использовать значение «next» чтобы перенаправить пользователя обратно на страницу, где они сначала нажали ссылку входа / выхода из системы.

Примечание: Попробуйте! Если вы находитесь на главной странице и вы нажимаете «Вход / Выход» на боковой панели, то после завершения операции вы должны вернуться на ту же страницу.

Тестирование в представлениях

Если вы используете функциональные представления, самым простым способом ограничить доступ к вашим функциям является применение login_required декоратор к вашей функции просмотра, как показано ниже. Если пользователь вошёл в систему, ваш код просмотра будет выполняться как обычно. Если пользователь не вошёл в систему, это перенаправит URL-адрес входа, определённый в настройках проекта. (settings.LOGIN_URL), передав текущий абсолютный путь в качестве next параметра URL. Если пользователю удастся войти в систему, они будут возвращены на эту страницу, но на этот раз аутентифицированы.

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

Примечание: Вы можете сделать то же самое вручную, путём тестирования request.user.is_authenticated, но декоратор намного удобнее!

Аналогичным образом, самый простой способ ограничить доступ к зарегистрированным пользователям в ваших представлениях на основе классов — это производные от LoginRequiredMixin. Вы должны объявить этот mixin сначала в списке суперкласса, перед классом основного представления.

from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    ...

Это имеет такое же поведение при переадресации, что и  login_required декоратор. Вы также можете указать альтернативное местоположение для перенаправления пользователя, если он не аутентифицирован (login_url), и имя параметра URL вместо «next» , чтобы вставить текущий абсолютный путь (redirect_field_name).

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'

Для получения дополнительной информации ознакомьтесь с  Django docs here.

Теперь, когда мы знаем, как ограничить страницу определённому пользователю, создайте представление о книгах, которые заимствовал текущий пользователь.

К сожалению, у нас пока нет возможности пользователям использовать книги! Поэтому, прежде чем мы сможем создать список книг, мы сначала расширим BookInstance модель для поддержки концепции заимствования и использования приложения Django Admin для заимствования ряда книг нашему тестовому пользователю.

Модели

Прежде всего, мы должны предоставить пользователям возможность кредита на BookInstance (у нас уже есть status и due_back дата, но у нас пока нет связи между этой моделью и пользователем. Мы создадим его с помощью поля ForeignKey (один ко многим). Нам также нужен простой механизм для проверки того, просрочена ли заёмная книга.

Откройте catalog/models.py, и импортируйте модель User из django.contrib.auth.models (добавьте это чуть ниже предыдущей строки импорта в верхней части файла, так User доступен для последующего кода, что позволяет использовать его):

from django.contrib.auth.models import User

Затем добавьте поле borrower в модель BookInstance:

borrower = models.ForeignKey(User, on_delete=models.SET_NULL, null=True, blank=True)

Пока мы здесь, давайте добавим свойство, которое мы можем вызвать из наших шаблонов, чтобы указать, просрочен ли конкретный экземпляр книги. Хотя мы могли бы рассчитать это в самом шаблоне, использование свойства, как показано ниже, будет намного более эффективным. Добавьте это где-нибудь в верхней части файла:

from datetime import date

Теперь добавьте следующее определение свойства внутри класса BookInstance:

@property
def is_overdue(self):
    if self.due_back and date.today() > self.due_back:
        return True
    return False

Примечание. Сначала мы проверим, является ли due_back пустым, прежде чем проводить сравнение. Пустое поле due_back заставило Django выкидывать ошибку, а не показывать страницу: пустые значения не сопоставимы. Это не то, что мы хотели бы, чтобы наши пользователи испытывали!

Теперь, когда мы обновили наши модели, нам нужно будет внести новые изменения в проект, а затем применить эти миграции:

python3 manage.py makemigrations
python3 manage.py migrate

Admin

Теперь откройте каталог catalog/admin.py, и добавьте поле borrower в класс BookInstanceAdmin , как в list_display , так и в полях fieldsets , как показано ниже. Это сделает поле видимым в разделе Admin, так что мы можем при необходимости назначить User в BookInstance.

@admin.register(BookInstance)
class BookInstanceAdmin(admin.ModelAdmin):
    list_display = ('book', 'status', 'borrower', 'due_back', 'id')
    list_filter = ('status', 'due_back')

    fieldsets = (
        (None, {
            'fields': ('book','imprint', 'id')
        }),
        ('Availability', {
            'fields': ('status', 'due_back','borrower')
        }),
    )

Займите несколько книг

Теперь, когда возможно кредитовать книги конкретному пользователю, зайдите и заработайте на нескольких записей в BookInstance. Установите borrowed поле вашему тестовому пользователю, сделайте status «В займе» и установите сроки оплаты как в будущем, так и в прошлом.

Примечание: Мы не будем описывать процесс, так как вы уже знаете, как использовать Admin сайт!

Займ в представлении

Теперь мы добавим представление для получения списка всех книг, которые были предоставлены текущему пользователю. Мы будем использовать один и тот же общий класс, с которым мы знакомы, но на этот раз мы также будем импортировать и выводить из  LoginRequiredMixin, так что только вошедший пользователь сможет вызвать это представление. Мы также решили объявить  template_name, вместо того, чтобы использовать значение по умолчанию, потому что у нас может быть несколько разных списков записей BookInstance, с разными представлениями и шаблонами.

Добавьте следующее в catalog/views.py:

from django.contrib.auth.mixins import LoginRequiredMixin

class LoanedBooksByUserListView(LoginRequiredMixin,generic.ListView):
    """
    Generic class-based view listing books on loan to current user.
    """
    model = BookInstance
    template_name ='catalog/bookinstance_list_borrowed_user.html'
    paginate_by = 10

    def get_queryset(self):
        return BookInstance.objects.filter(borrower=self.request.user).filter(status__exact='o').order_by('due_back')

Чтобы ограничить наш запрос только объектами BookInstance для текущего пользователя, мы повторно реализуем get_queryset(), как показано выше.mybooks/$’, views.LoanedBooksByUserListView.as_view(), name=’my-borrowed’),
]

Шаблон для заёмных книг

Теперь все, что нам нужно сделать для этой страницы, — это добавить шаблон. Сначала создайте файл шаблона /catalog/templates/catalog/bookinstance_list_borrowed_user.html и дайте ему следующее содержание:

{% extends "base_generic.html" %}

{% block content %}
    <h2>Borrowed books</h2>

    {% if bookinstance_list %}
    <ul>

      {% for bookinst in bookinstance_list %}
      <li>
        <a href="{% url 'book-detail' bookinst.book.pk %}">{{bookinst.book.title}}</a> ({{ bookinst.due_back }})
      </li>
      {% endfor %}
    </ul>

    {% else %}
      <p>There are no books borrowed.</p>
    {% endif %}
{% endblock %}

Этот шаблон очень похож на тот, который мы создали ранее для объектов Book и Author. Единственное, что «новое» здесь, это то, что мы проверяем метод, который мы добавили в модель (bookinst.is_overdue) с целью использовать его для изменения цвета просроченных предметов.

Когда сервер разработки запущен, вы должны теперь иметь возможность просматривать список для зарегистрированного пользователя в своём браузере по адресу  http://127.0.0.1:8000/catalog/mybooks/. Попробуйте это, когда ваш пользователь войдёт в систему и выйдет из системы (во втором случае вы должны быть перенаправлены на страницу входа в систему).

Добавить список на боковую панель

Последний шаг — добавить ссылку на эту новую страницу в sidebar. Мы поместим это в тот же раздел, где мы покажем другую информацию для зарегистрированного пользователя.

Откройте базовый шаблон (/locallibrary/catalog/templates/base_generic.html) и добавьте выделенную строку из sidebar, как показано на рисунке.

 <ul>
   {% if user.is_authenticated %}
   <li>User: {{ user.get_username }}</li>
   <li><a href="{% url 'my-borrowed' %}">My Borrowed</a></li>
   <li><a href="{% url 'logout'%}?next={{request.path}}">Logout</a></li>
   {% else %}
   <li><a href="{% url 'login'%}?next={{request.path}}">Login</a></li>
   {% endif %}
 </ul>

На что это похоже?

Когда любой пользователь войдёт в систему, он будет видеть ссылку «Мной позаимствовано (My Borrowed)» в боковой колонке, и список книг, показанных ниже (первая книга не имеет установленной даты, что является ошибкой, которую мы надеемся исправить в более позднем уроке!).

Права доступа связаны с моделями и определяют операции, которые могут выполняться на экземпляре модели самим пользователем, у которого есть разрешение. По умолчанию Django автоматически даёт добавить, изменить, и удалить разрешения у всех моделей, которые позволяют пользователям с правом доступа выполнять связанные действия через администратора сайта. Вы можете определить свои собственные разрешения для моделей и предоставить их конкретным пользователям. Вы также можете изменить разрешения, связанные с разными экземплярами одной и той же модели. Тестирование разрешений в представлениях и шаблонах очень похоже на тестирование по статусу аутентификации (фактически, тестирование прав доступа также проверяет аутентификацию).

Модели

Определение разрешений выполняется в разделе моделей «class Meta» , используется permissions поле. Вы можете указать столько разрешений, сколько необходимо в кортеже, причём каждое разрешение определяется во вложенном кортеже, содержащем имя разрешения и отображаемое значение разрешения. Например, мы можем определить разрешение, позволяющее пользователю отметить, что книга была возвращена, как показано здесь:

class BookInstance(models.Model):
    ...
    class Meta:
        ...
        permissions = (("can_mark_returned", "Set book as returned"),)   

Затем мы могли бы назначить разрешение группе «Библиотекарь» (Librarian) на сайте администратора.

Откройте catalog/models.py, и добавьте разрешение, как показано выше. Вам нужно будет повторно выполнить миграцию (вызвав python3 manage.py makemigrations и python3 manage.py migrate) для надлежащего обновления базы данных.

Шаблоны

Разрешения текущего пользователя хранятся в переменной шаблона, называемой  {{ perms }}. Вы можете проверить, имеет ли текущий пользователь определённое разрешение, используя конкретное имя переменной в соответствующем приложении «Django» — например, {{ perms.catalog.can_mark_returned }} будет True если у пользователя есть это разрешение, а False — в противном случае. Обычно мы проверяем разрешение с использованием шаблона {% if %}, как показано в:

{% if perms.catalog.can_mark_returned %}
    <!-- We can mark a BookInstance as returned. -->
    <!-- Perhaps add code to link to a "book return" view here. -->
{% endif %}

Представления

Разрешения можно проверить в представлении функции, используя  permission_required декоратор или в представлении на основе классов, используя PermissionRequiredMixin. шаблон и поведение такие же, как для аутентификации входа в систему, хотя, конечно, вы можете разумно добавить несколько разрешений.

Функция в представлении с декоратором:

from django.contrib.auth.decorators import permission_required

@permission_required('catalog.can_mark_returned')
@permission_required('catalog.can_edit')
def my_view(request):
    ...

Требуется разрешение mixin для представлений на основе классов.

from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'catalog.can_mark_returned'
    
    permission_required = ('catalog.can_mark_returned', 'catalog.can_edit')
    
    

Пример

Мы не будем обновлять LocalLibrary здесь; возможно, в следующем уроке!

 Ранее в этой статье мы показали вам, как создать страницу для текущего пользователя, в которой перечислены книги, которые они заимствовали. Теперь задача состоит в том, чтобы создать аналогичную страницу, которая видна только для библиотекарей, которая отображает  все книги, которые были заимствованы, и которая показывает имя каждого заёмщика.

 Вы должны следовать той же схеме, что и для другого представления. Главное отличие состоит в том, что вам нужно ограничить представление только библиотекарями. Вы можете сделать это на основе того, является ли пользователь сотрудником (декоратор функции:  staff_member_required, переменная шаблона: user.is_staff) но мы рекомендуем вам вместо этого использовать  can_mark_returned разрешения и PermissionRequiredMixin, как описано в предыдущем разделе.

Важно: Не забудьте использовать вашего суперпользователя для тестирования на основе разрешений (проверки разрешений всегда возвращают true для суперпользователей, даже если разрешение ещё не определено!). Вместо этого создайте пользователя-библиотекаря и добавьте необходимые возможности.

 Когда вы закончите, ваша страница должна выглядеть примерно, как на скриншоте ниже.

 Отличная работа — теперь вы создали веб-сайт, на котором участники библиотеки могут входить в систему и просматривать собственный контент, и библиотекари (с правом доступа) могут просматривать все заёмные книги с их читателями. На данный момент мы все ещё просто просматриваем контент, но те же принципы и методы используются, когда вы хотите начать изменять и добавлять данные.

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

Как сделать регистрацию и авторизацию пользователей на сайте

Вы здесь:
Главная — PHP — PHP Основы — Как сделать регистрацию и авторизацию пользователей на сайте

Не так давно один из моих посетителей попросил меня написать статью о том, как сделать регистрацию и авторизацию пользователей на сайте. Собственно, выполняю его просьбу, и в этой статье я расскажу о том, как это делается.

Существует несколько способов создания регистрации и авторизации пользователей, но в этой статье я разберу свой любимый — через механизм сессий или cookie.

Первым делом, если Вы хотите сделать регистрацию у себя на сайте, то необходимо понимать, где будут храниться данные о пользователях. Можно хранить в обычном текстовом файле, в XML-файле, либо в базе данных. Первые два варианта — очень опасные, поэтому не рекомендую Вам ими пользоваться. А вот третий вариант — хранение информации о пользователях в базе данных — самый популярный, и именно этим способом хранения информации я советую Вам пользоваться.

С местом хранения определились. Теперь перейдём непосредственно к алгоритму авторизации:

1. Создать форму регистрации на HTML.
2. Получить данные из формы в скрипте-обработчике.
3. Проверить полученные данные, и если они некорректны, то сделать редирект обратно на форму регистрации.
4. Если данные корректны, то записать их в базу данных.

Вот и весь процесс регистрации пользователя на сайте. То есть регистрация — это сохранение информации о пользователе на сайте.

Дальнейшим пунктом является авторизация пользователя на сайте, однако, прежде чем к нему переходить, расскажу об одном важном моменте в форме регистрации — пароле. Я Вам настоятельно рекомендую не хранить пароли в открытом виде (например так, «123456«). Обязательно их шифруйте, хотя бы с помощью функции md5(). И в базе данных храните именно зашифрованный пароль.

Теперь авторизация. Первое, что Вы должны понять — это то, что информация об авторизации должна где-то храниться. Самый простой вариант — это хранение информации в сессии (или в cookie). А теперь алгоритм:

1. Создать форму авторизации пользователя на HTML, куда пользователь должен будет ввести свой логин и пароль.
2. В скрипте-обработчике принять данные от пользователя. Если Вы меня послушались, и храните шифрованные пароли в базе данных, то сначала шифруйте полученный пароль. Если же в базе данных лежат открытые пароли, то шифровать не надо.
3. Проверить правильность введённых данных, и если логин и пароль совпадают с существующим пользователем в базе данных, то записываете в cookie или сессию информацию с логином и шифрованным паролем (либо открытым паролем, если Вы его не шифровали).
4. Если логин и/или пароль введены неверно, то делать редирект обратно на форму авторизации.

Теперь у Вас есть необходимая информация об авторизации пользователя, которая хранится в его cookie или на сервере (если сессия). Фактически, теперь Вам нужно эту информацию проверять на каждой странице сайта и сверять её аналогично проверке формы авторизации. То есть считываете из cookie (сессии) логин и пароль, и проверяете его. Если они верные, то показываете одну страницу (для зарегистрированных пользователей), а если неверные, то показываете другую страницу (для гостей).

И последнее. Как делается кнопка «Выход«? Очень просто. При нажатии на эту кнопку, стираются cookie, либо сессия. Таким образом, пользователь автоматически вылетает с сайта.

Как видите, всё элементарно, но при реализации этого алгоритма у Вас обязательно возникнет множество вопросов. Например, что делать при регистрации пользователя, логин которого уже имеется в базе данных. Реализация различных проверок входных данных, реализация проверки существования e-mail и прочее — всё это является достаточно сложным, если Вы делаете это в первый раз. Однако, самый сок я выдал. Если будут вопросы при реализации, то спрашивайте либо на форуме, либо в комментариях.

В данной статье я привёл лишь алгоритм, а чтобы научиться его реализовывать нужно знать PHP и MySQL, которые максимально подробно разобраны в этом обучающем курсе: http://srs.myrusakov.ru/php

• 
  Создано 05.05.2011 13:05:46

• 
  
  Михаил Русаков

Предыдущая статья Следующая статья

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

1. 
   Кнопка:
   
   <a href=»https://myrusakov.ru» target=»_blank»><img src=»https://myrusakov.ru/images/button.gif» alt=»Как создать свой сайт» /></a>

   Она выглядит вот так:

2. 
   Текстовая ссылка:
   <a href=»https://myrusakov.ru» target=»_blank»>Как создать свой сайт</a>

   Она выглядит вот так: Как создать свой сайт

3. BB-код ссылки для форумов (например, можете поставить её в подписи):
   
   [URL=»https://myrusakov.ru»]Как создать свой сайт[/URL]

Оптимизация регистрации и авторизации на сайте

Как авторизация и регистрация на сайте влияет на основные показатели интернет-магазина? Как мотивировать пользователей создать аккаунт? В этой статье вы найдете практические советы UX/UI эксперта по оформлению и оптимизации процесса, чтобы он был максимально удобный и быстрый для пользователя и приносил доход интернет-магазину.

5 практических советов по оптимизации авторизации на сайте

1. Размещайте вход в личный кабинет в привычном месте

Это и есть UX — опыт использования и взаимодействия с сайтом. Многие привыкли к тому, что кабинет и корзина находятся в правом верхнем углу. Поэтому не нарушайте устоявшиеся паттерны. Постоянные пользователи будут искать вход в систему на привычном месте и, если не найдут его там, то могут растеряться и покинуть сайт, что повлияет на конверсию.

В дизайне интерфейса сайта Zlato.ua соблюдены привычные паттерны размещения элементов входа в личный кабинет

2. Реализуйте авторизацию и регистрацию в одно окно

От 20% до 60% пользователей часто восстанавливают пароли, потому что забывают их. Поэтому стоит использовать одноразовый пароль. Реализуйте авторизацию и регистрацию в одно окно — пользователь вводит свои данные и если он зарегистрирован, то авторизуется, а если нет — то регистрируется. Таким образом вы проявите заботу о клиенте, сделаете процесс проще и безопаснее.

Пример реализации регистрации и авторизации в одно окно на сайте Infoshina

Вот еще несколько решений, которые помогут упростить и ускорить регистрацию и авторизацию на сайте:

• Если пользователь ошибся, обязательно укажите поле, где допущена ошибка (логин, формат телефона и т.д.).
• 
  Внедрите функционал для проверки правильности введения данных еще до отправки формы.

Например, на сайте Zlato.ua пользователь может просмотреть пароль для проверки правильно ли он его ввел или нет до того, как нажмет на кнопку «Войти»

• Проявите заботу о клиенте и добавьте ссылку на форму восстановления пароля, так чтобы можно было быстро его восстановить при необходимости
• 
  Стоит запоминать пользователя, который авторизовался, чтобы ему не пришлось входить в систему заново, если он случайно закрыл вкладку или окно браузера. В таком случае, чтобы обеспечить безопасность, дополнительно запросите пароль при оформлении заказа и оплате онлайн.

3. Предложите авторизацию по номеру телефона

Все больше пользователей предпочитают авторизацию на сайте по номеру телефона, а не через email. Это дополнительная причина использовать одноразовый пароль для авторизации.

Пример реализации регистрации и авторизации в одно окно по номеру телефона на сайте Pratik

В этом случае на указанный пользователем номер телефона приходит SMS с кодом-паролем для входа в личный кабинет. Это и безопасно, и удобно — пользователь подтверждает вход с телефона и при этом ему не надо ничего запоминать. Также можно использовать различные популярные мессенджеры для отправки кода — выберите тот, который максимально удобен именно вашей целевой аудитории.

Так вы уменьшаете порог вхождения новых и постоянных пользователей, что положительно влияет на основные KPI интернет-магазина.

4. Реализуйте авторизацию через социальные сети

Согласно статистике, для авторизации на сайте 44,8% пользователей используют Google и 53% — Facebook. Такой способ авторизации поможет сократить путь пользователя и максимально упростить процесс регистрации и авторизации.

Пример различных вариантов авторизации на сайте Antoshka

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

Но стоит также учесть некоторые нюансы:

• Есть вероятность, что клиент забудет какую именно социальную сеть для авторизации он использовал ранее;
• 
  При удалении аккаунта в социальной сети, пользователь не сможет войти в личный кабинет на вашем сайте.

5. Сохраняйте положение пользователя

Желание или необходимость зарегистрироваться либо авторизоваться могут появиться на любом этапе взаимодействия с сервисом. Поэтому важно вернуть пользователя на тот же шаг, с которого он перешел, сразу после авторизации, чтобы он продолжил свой путь по воронке, иначе он попросту уйдет. 

Авторизация без перехода на отдельную страницу формы (popup, модальное окно, и т.д.) поможет сохранить положение пользователя независимо от того на каком этапе он решил войти в систему и после обновления страницы.

Реализация авторизации без перехода в отдельное окно и с сохранением положения пользователя на сайте ТехноЁж

9 практических советов по оптимизации регистрации на сайте

1. Не требуйте регистрацию

37% пользователей не станут оформлять заказ и уйдут к конкуренту из-за необходимости регистрации. Поэтому сделайте регистрацию необязательной, предоставив пользователям возможность выбора.

Например, при заказе на сайте 966.ua пользователь может выбрать Быструю покупку или Заполнить подробную форму

Также стоит избегать таких формулировок, как «Регистрация» и «Авторизация», замените их на «Войти», «Личный кабинет», «Новый клиент» и т.д.

Пример предложения регистрации на сайте MonAmie

2. Покажите преимущества регистрации

Если преимущества регистрации клиентов очевидны для бизнеса, то покупателю может быть непонятно для чего ему это. Организуйте систему лояльности с бонусами, личными скидками и промокодами. Так вы выстроите взаимоотношения с клиентами, повысите LTV пользователя и увеличите доход интернет-магазина, помните, что ARРU лояльных пользователей в 3 раза выше, чем новых.

Сообщите о преимуществах зарегистрированных пользователей, чтобы убедить пользователя заполнить форму:

• История заказов с возможностью повторить их;
• 
  Проверка статуса заказа;
• 
  Сохранение адресов доставки, контактов получателей, способов оплаты и т.д.;
• 
  Начисление бонусов за покупки, программа лояльности, личная скидка;
• 
  Сохранение понравившихся товаров в «Избранное»;
• 
  История просмотров;
• 
  Участия в закрытых акциях;
• 
  Получение рассылки со специальными и эксклюзивными предложениями, информацией о распродажах, акциях, скидках на интересующие их товары, и прочее.

Пример формы регистрации на сайте Pampikс демонстрацией преимуществ 

3. Сделайте фоновую регистрацию

Предоставьте пользователям выбор — создать учетную запись или оформить заказ без регистрации. Позвольте пользователю быть гостем и используйте фоновую регистрацию. Дело в том, что даже без регистрации, пользователю необходимо ввести определенные данные для совершения покупки, которых достаточно для создания аккаунта. В таком случае вы можете просто зарегистрировать пользователя без акцентирования внимания на этом и выслать регистрационные данные по email, например.

4. Максимально сократите количество полей в форме регистрации

Не акцентируйте внимание на полях формы регистрации и минимизируйте их количество. Стоит визуально выделить обязательные поля, а лучше запросить остальную информацию о пользователе уже после регистрации. Например, узнайте фамилию в поле «Получатель» при оформлении заказа, так покупатель будет понимать для чего вам нужна данная информация.

Пример реализации регистрации на сайте Zlato.ua

5. Сделайте акцент на эксклюзивности

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

Пример реализации сообщества в детском интернет-магазине Антошка

6. Откажитесь от капчи

Согласно исследованию, только 66% пользователей смогут ввести капчу без ошибок с первого раза, при этом после двух неудачных попыток подряд, пользователь просто уйдет. Так даже хорошо реализованная капча приводит к потере клиентов. Поэтому от нее стоит либо отказаться, либо использовать скрытую капчу.

Но в случае, если она необходима, то следует взять во внимание следующие советы:

• Используйте хорошо различимые и читаемые буквы и символы;
• 
  Не делайте капчу чувствительной регистру;
• 
  Не очищайте содержимое полей, если пользователь ошибся при вводе капчи;
• 
  Запрашивайте введение капчи только один раз за весь сеанс.

7. Сохраняйте внесенные данные при ошибке

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

8. Откажитесь от необходимости активировать аккаунт

Откажитесь от активации аккаунта, чтобы сократить путь пользователя. Предоставьте пользователю доступ к личному кабинету и его функциональности сразу же после регистрации.

9. Пишите понятные заголовки в рассылке

Если пользователь забыл пароль, первое, что он попробует сделать — это найти приветственное письмо со всеми регистрационными данными. Облегчите задачу пользователю, сделав понятную тему письма с указанием названия интернет-магазина и пометкой о чем email. Например: «Регистрационные данные в …». Используйте название вашего интернет-магазина в поле отправителя.

Слишком сложный и долгий процесс регистрации и авторизации может негативно повлиять на общую эффективность сайта и привести к потере клиентов. Чтобы сделать сервис более клиентоориентированным, вам стоит:

• Сделать регистрацию необязательной или фоновой;
• 
  Реализовать регистрацию и авторизацию в одно окно;
• 
  Внедрить регистрацию по номеру телефона с одноразовым кодом-паролем;
• 
  Предложить регистрацию и авторизацию через соцсети.

Аутентификация без регистрации — Information Security Stack Exchange

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

Вы могли бы усложнить задачу. Использование закрепления сертификата на стороне приложения, что затрудняет анализ трафика, а обфускация двоичного файла замедлит потенциальных злоумышленников, которые хотят воспроизвести поведение вашего приложения, но даже в этом случае злоумышленнику просто нужно удалить / переустановить ваше приложение, и оно » будет отображаться как новая установка на большинстве устройств.

Если возможно, на ваших целевых устройствах вы должны полагаться на идентификатор, предоставленный ОС хоста или магазином приложений — его труднее реплицировать (или даже невозможно, если ваш сервер связывается с серверами магазина приложений для проверки установки вашего приложения) чем репликация приложения, поскольку у ОС есть способы доступа к оборудованию и получения от него идентификаторов устройств (MAC-адрес, IMEI и т. д.), в то время как ваше приложение не может получить к ним доступ напрямую.

Вы также можете привязать уникальные идентификаторы устройств к чему-то более сложному для получения, например к номерам телефонов, требуя подтверждения по SMS при каждой установке приложения. Это не остановит мошенничество (и как таковое не подходит для «формального» голосования, такого как выборы или что-то еще, где задействованы деньги), но это поможет. Это похоже на DRM, оно не обязательно должно быть пуленепробиваемым, оно просто должно быть сильнее, чем приложения конкурента, и злоумышленники будут преследовать низко висящие плоды, оставив ваше решение в покое.

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

4 способа доступа к API с помощью OAuth без взаимодействия с пользователем — автоматический вход OAuth3 с помощью Facebook, Google или любого другого API — блог пакета библиотеки PHP OAuth

Содержание

Доступ к API с помощью OAuth без взаимодействия с пользователем

1. Обычный OAuth Доступ к API

2.Автоматическое обновление просроченных токенов

3. Авторизация с паролем пользователя

4. Доступ только к приложениям с client_credentials

Загрузите класс PHP OAuth для доступа к API без взаимодействия с пользователем

Доступ к API с помощью OAuth без взаимодействия с пользователем

OAuth стал стандарт де-факто для доступа к веб-интерфейсам API, требующим авторизации перед вызовом функций API.

Обычно необходимо, чтобы пользователь дал разрешение на доступ к API от своего имени.Однако также можно получить доступ к API без присутствия пользователя, а в некоторых случаях и без авторизации реального пользователя.

Класс PHP OAuth поддерживает несколько способов вызова API без взаимодействия с пользователем. Давайте посмотрим на каждый из этих методов доступа и на то, как вы можете реализовать их с помощью клиентского класса OAuth.

1. Обычный доступ к API OAuth

При обычном доступе к API OAuth пользователь должен присутствовать, чтобы предоставить приложению авторизацию для доступа к API.После предоставления авторизации пользователю не нужно присутствовать, чтобы приложение могло выполнять вызовы API.

Итак, пока токены авторизации установлены и не истек срок их действия, ваше приложение может выполнять столько вызовов API, сколько необходимо.

Имейте в виду, что по умолчанию клиентский класс OAuth использует сеансы PHP для хранения токенов OAuth, полученных в процессе авторизации. Сеансы PHP действительны только тогда, когда пользователь обращается в качестве веб-страницы того же сайта, на котором был создан сеанс.

Итак, если вашему приложению необходимо выполнять вызовы API, когда пользователя нет, ему необходимо где-то хранить токены, чтобы их можно было получить, когда они понадобятся вашему приложению.

Обычный способ хранить и извлекать токены — использовать базу данных. Вы можете написать свой собственный код приложения для хранения токенов в базе данных вашего приложения. Обычно вы храните одну запись в таблице базы данных для каждого пользователя, авторизовавшего доступ к API через OAuth.

В этом случае вам нужно знать, какие переменные класса OAuth вам нужно сохранить и восстановить позже.Эти переменные: access_token , access_token_secret (серверы только OAuth 1), access_token_expiry (для истекающих токенов), access_token_type , refresh_token (для токенов, которые могут быть обновлены по истечении срока их действия).

В качестве альтернативы вы можете использовать подкласс класса клиента OAuth, который поставляется с этим пакетом, для хранения токенов в вашей базе данных. В настоящее время пакет поставляется со скриптом подкласса mysqli_oauth_client.php для хранения значений токенов в базе данных MySQL.Вы можете создать другие подклассы подкласса database_oauth_client.php, если предпочитаете использовать другую базу данных.

2. Автоматическое обновление истекших токенов

Некоторые серверы API выдают токены OAuth, срок действия которых истекает через некоторое время. Эти токены необходимо обменять на новые по истечении срока их действия. Это делается путем отправки нового запроса на сервер API с использованием токена обновления, полученного ранее при получении последнего токена доступа.

Новый маркер доступа и возможный новый маркер обновления заменяют старые маркеры.Таким образом, вы отказываетесь от старых жетонов и с этого момента используете новые.

Замена нового токена произойдет в следующий раз, когда вы сделаете вызов API, а срок действия старого токена истечет. Поэтому очень важно, чтобы ваше машинное время было абсолютно точным или, по крайней мере, не задерживалось.

Обновление просроченных токенов — это немного сложный процесс, но, к счастью, класс клиента OAuth прозрачно позаботится об этом. Если вы используете один из классов базы данных, упомянутых выше, они позаботятся о процессе замены токена, сохраняя новые токены в базе данных.

Если вы не используете один из этих классов базы данных, вам необходимо проверить упомянутые выше переменные и при необходимости обновить сохраненные токены.

Некоторые API, такие как, например, Google, выдают токены обновления только в том случае, если вы используете специальный URL для получения токенов. К счастью, класс OAuth также может позаботиться об этом, используя правильный URL-адрес токена. Просто установите для переменной класса offline значение true, и он будет использовать специальный URL-адрес для получения токена обновления, чтобы он мог автоматически обновлять истекшие токены позже.

Доступ к API в автономном режиме с использованием базы данных для хранения извлеченных токенов и обновления токенов для замены просроченных токенов уже объяснялся в более подробной статье об автономном доступе к API на основе OAuth.

Другие API, такие как, например, Facebook, выдают токены доступа, срок действия которых истекает через некоторое время, но не может быть продлен автоматически. В этом случае вам нужно предложить пользователю зайти на сайт и снова пройти весь процесс авторизации OAuth с самого начала.

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

3. Авторизация с помощью пароля пользователя

Некоторые приложения не предназначены для доступа к API от имени других пользователей, а только для одного пользователя, который является разработчиком приложения. В этом случае есть API, которые могут возвращать токен доступа, используя только имя пользователя и пароль разработчика приложения.

Это хорошо, потому что пользователь-разработчик не должен присутствовать при запросе токена доступа. Ему просто нужно предоставить свое имя пользователя и пароль для своих сценариев приложения, которые обращаются к API.Это называется потоком авторизации учетных данных с паролем владельца ресурса.

Класс клиента OAuth также поддерживает этот процесс авторизации на основе пароля. Все, что вам нужно сделать, это установить переменные класса oauth_username и oauth_password на имя пользователя и пароль разработчика соответственно.

Процесс вызова API такой же, как и для обычного потока OAuth с использованием функции CallAPI.

Существуют API, такие как, например, Salesforce, которые поддерживают этот тип процесса авторизации на основе пароля.

4. Доступ только для приложений с client_credentials

Другой формой выполнения вызовов API без взаимодействия с пользователем является выполнение вызовов API только для приложений с использованием учетных данных клиента, то есть значений учетных данных приложения, которые вы установили в client_id и client_secret переменные.

В этом случае вам необходимо установить для переменной класса grant_type значение client_credentials . Таким образом, класс получает токен доступа автоматически, не требуя присутствия пользователя, как и в случае с потоком авторизации на основе пароля.Единственное отличие состоит в том, что вам никогда не нужно указывать имя пользователя или пароль для ваших скриптов.

API-интерфейсы, такие как Twitter, поддерживают только авторизацию приложений этого типа с использованием протокола OAuth 2. Имейте в виду, что для обычного доступа к OAuth API от имени реального пользователя вам необходимо вместо этого использовать протокол OAuth 1.0a. Класс клиента OAuth поддерживает оба типа потока авторизации OAuth.

Загрузить класс PHP OAuth для доступа к API без взаимодействия с пользователем

OAuth — довольно сложный протокол, особенно потому, что существует две основные версии протокола и нет единого мнения относительно того, какую версию использует каждый API.

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

Кроме того, класс поставляется с отдельным файлом конфигурации с именем oauth_configuration.json, который определяет значения для настройки класса для различных типов хорошо известных серверов API на основе OAuth. Таким образом, вам практически нужно только установить переменную класса сервера на имя сервера API, к которому вы хотите получить доступ, таким образом, не тратя слишком много времени на изучение протокола OAuth.

Тем не менее, могут быть другие серверы, для которых еще нет заранее определенной конфигурации, чтобы вы могли быстро начать работу. Если вы хотите использовать один из этих серверов или у вас есть другие вопросы, оставьте комментарий к этой статье сейчас.

Вы можете использовать этот пакет, загрузив ZIP-архив с вкладки загрузки, или установить с помощью инструмента композитора, используя инструкции, представленные также на вкладке загрузки.

Получите доступ без пользователя — Microsoft Graph

• 04.06.2021
• Читать 9 минут

В этой статье

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

Приложения, которые вызывают Microsoft Graph со своим идентификатором, используют OAuth 2.0 клиентские учетные данные предоставляют поток для получения токенов доступа из Azure AD. В этом разделе описаны основные шаги по настройке службы и использованию потока предоставления учетных данных клиента OAuth для получения токена доступа.

Этапы аутентификации и авторизации

Основные шаги, необходимые для настройки службы и получения токена от конечной точки платформы идентификации Microsoft, который ваша служба может использовать для вызова Microsoft Graph под собственной идентификацией:

1. Зарегистрируйте свое приложение.
2. Настройте разрешения для Microsoft Graph в своем приложении.
3. Получите согласие администратора.
4. Получите токен доступа.
5. Используйте токен доступа для вызова Microsoft Graph.

1. Зарегистрируйте приложение

Для проверки подлинности с помощью конечной точки платформы идентификации Microsoft необходимо сначала зарегистрировать свое приложение на портале регистрации приложений Azure. Вы можете использовать учетную запись Microsoft, рабочую или учебную учетную запись для регистрации своего приложения.

Для службы, которая будет вызывать Microsoft Graph под своим собственным удостоверением, вам необходимо зарегистрировать свое приложение для веб-платформы и скопировать следующие значения:

• Идентификатор приложения, присвоенный порталом регистрации приложений Azure.
• Секрет клиента (приложения), либо пароль, либо пара открытого / закрытого ключей (сертификат).
• URL-адрес перенаправления для вашей службы для получения ответов на токены.
• URL-адрес перенаправления для вашей службы для получения ответов о согласии администратора, если ваше приложение реализует функцию запроса согласия администратора.

Инструкции по настройке приложения с помощью портала регистрации приложений Azure см. В разделе Регистрация приложения.

С помощью потока предоставления учетных данных клиента OAuth 2.0 ваше приложение аутентифицируется непосредственно на конечной точке платформы идентификации Microsoft / токен , используя идентификатор приложения, назначенный Azure AD, и секрет приложения, который вы создаете с помощью портала.

2. Настройте разрешения для Microsoft Graph

Для приложений, которые вызывают Microsoft Graph под своим собственным удостоверением, Microsoft Graph предоставляет разрешения для приложений (Microsoft Graph также может предоставлять делегированные разрешения для приложений, которые вызывают Microsoft Graph от имени пользователя). Вы предварительно настраиваете разрешения приложения, необходимые вашему приложению, когда вы регистрируете свое приложение. Разрешения приложения всегда требуют согласия администратора. Администратор может либо дать согласие на эти разрешения с помощью портала Azure, когда ваше приложение установлено в их организации, либо вы можете предоставить возможность регистрации в своем приложении, с помощью которой администраторы могут дать согласие на настроенные вами разрешения.После регистрации согласия администратора в Azure AD ваше приложение может запрашивать токены без повторного запроса согласия. Дополнительные сведения о разрешениях, доступных в Microsoft Graph, см. В справочнике по разрешениям

.

Чтобы настроить разрешения для вашего приложения на портале регистрации приложений Azure: на странице разрешений API приложения выберите Добавить разрешение , выберите Microsoft Graph , а затем выберите разрешения, необходимые вашему приложению в разделе Разрешения для приложений .

На следующем снимке экрана показано диалоговое окно Выбор разрешений для разрешений приложения Microsoft Graph.

Примечание : Мы рекомендуем настроить набор разрешений с минимальными правами, необходимый для вашего приложения. Это обеспечивает гораздо более удобную работу для администраторов, чем необходимость давать согласие на длинный список разрешений.

3. Получите согласие администратора

Вы можете положиться на администратора в предоставлении разрешений, необходимых вашему приложению на портале Azure; однако зачастую лучшим вариантом является предоставление администраторам возможности регистрации с использованием конечной точки платформы Microsoft Identity / adminconsent .

Важно : Каждый раз, когда вы вносите изменения в настроенные разрешения, вы также должны повторять процесс согласия администратора. Изменения, внесенные на портале регистрации приложений, не будут отражены до тех пор, пока администратор клиента повторно не подаст согласие.

Запрос

  // Разрывы строк предназначены только для удобства чтения.

ПОЛУЧИТЬ https://login.microsoftonline.com/{tenant}/adminconsent
? client_id = 6731de76-14a6-49ae-97bc-6eba6914391e
& state = 12345
& redirect_uri = https: // localhost / myapp / разрешения
  

Опыт согласия администратора

С запросами к конечной точке / adminconsent Azure AD обеспечивает, чтобы только администратор клиента мог войти в систему для выполнения запроса.Администратору будет предложено утвердить все разрешения приложения, которые вы запросили для своего приложения на портале регистрации приложений.

Ниже приведен пример диалогового окна согласия, которое Azure AD представляет администратору:

Ответ

Если администратор утверждает разрешения для вашего приложения, успешный ответ будет выглядеть так:

  // Разрывы строк предназначены только для удобства чтения.

ПОЛУЧИТЬ https: // localhost / myapp / permissions
? tenant = a8990e1f-ff32-408a-9f8e-78d3b9139b95 & state = 12345
& admin_consent = Верно
  

Попробуйте : вы можете попробовать это сами, вставив следующий запрос в браузер.Если вы войдете в систему как глобальный администратор для клиента Azure AD, вам будет представлено диалоговое окно согласия администратора для приложения. (Это будет приложение, отличное от того, что показано на скриншоте диалогового окна согласия, показанном ранее.)

https://login.microsoftonline.com/common/adminconsent?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&state=12345&redirect_uri=https://localhost/myapp/permissions

4. Получите токен доступа

В потоке предоставления учетных данных клиента OAuth 2.0 вы используете значения идентификатора приложения и секрета приложения, которые вы сохранили при регистрации приложения, чтобы запросить маркер доступа непосредственно из конечной точки платформы Microsoft Identity / token .

Вы указываете предварительно настроенные разрешения, передавая https://graph.microsoft.com/.default в качестве значения для параметра области в запросе токена. Подробности см. В описании параметра области в запросе токена ниже.

Запрос токена

Вы отправляете запрос POST на конечную точку платформы идентификации / token для получения маркера доступа:

  // Разрывы строк предназначены только для удобства чтения.

POST https: // логин.microsoftonline.com/{tenant}/oauth3/v2.0/token HTTP / 1.1
Хост: login.microsoftonline.com
Тип содержимого: application / x-www-form-urlencoded

client_id = 535fb089-9ff3-47b6-9bfb-4f1264799865
& scope = https% 3A% 2F% 2Fgraph.microsoft.com% 2F.default
& client_secret = qWgdYAmab0YSkuL1qKv5bPX
& grant_type = client_credentials
  

Ответ токена

Успешный ответ выглядит так:

  {
  "token_type": "На предъявителя",
  "expires_in": 3599,
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBP ..."
}
  

5. Используйте токен доступа для вызова Microsoft Graph

Получив токен доступа, вы можете использовать его для вызова Microsoft Graph, включив его в заголовок Authorization запроса. Следующий запрос получает профиль конкретного пользователя. Ваше приложение должно иметь User.Read.Все разрешений на вызов этого API.

  ПОЛУЧИТЬ https://graph.microsoft.com/v1.0/users/12345678-73a6-4952-a53a-e9916737ff7f
Авторизация: предъявитель eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw
Хост: graph.microsoft.com
  

Успешный ответ будет выглядеть примерно так (некоторые заголовки были удалены):

  HTTP / 1.1 200 ОК
Content-Type: application / json; odata.metadata = minimal; odata.streaming = true; IEEE754Compatible = false; charset = utf-8
идентификатор запроса: f45d08c0-6901-473a-90f5-7867287de97f
идентификатор-запроса-клиента: f45d08c0-6901-473a-90f5-7867287de97f
OData-Версия: 4.0
Продолжительность: 309.0273
Дата: среда, 26 апреля 2017 г., 19:53:49 GMT
Длина содержимого: 407
  

  {
    "@ odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
    "id": "12345678-73a6-4952-a53a-e9916737ff7f",
    "businessPhones": [
        "+1 555555555"
    ],
    "displayName": "Крис Грин",
    "givenName": "Крис",
    "jobTitle": "Инженер-программист",
    "mail": null,
    "mobilePhone": "+ 1 5555555555",
    "officeLocation": "Офис в Сиэтле",
    "предпочтительный язык": нуль,
    "фамилия": "Зеленый",
    "userPrincipalName": "ChrisG @ contoso.onmicrosoft.com "
}
  

Поддерживаемые сценарии приложений и ресурсы

Приложения, вызывающие Microsoft Graph под собственным именем, можно разделить на две категории:

• Фоновые службы (демоны), которые работают на сервере без вошедшего в систему пользователя.
• Приложения, у которых есть зарегистрированный пользователь, но которые также вызывают Microsoft Graph со своим идентификатором; например, для использования функций, требующих более высоких привилегий, чем у пользователя.

Приложения, которые вызывают Microsoft Graph со своим идентификатором, используют OAuth 2.0 предоставить учетные данные клиента для аутентификации в Azure AD и получения токена. Для конечной точки платформы Microsoft Identity вы можете дополнительно изучить этот сценарий с помощью следующих ресурсов:

Рекомендации по конечным точкам

Microsoft продолжает поддерживать конечную точку Azure AD. Существует несколько различий между использованием конечной точки платформы идентификации Microsoft и конечной точки Azure AD. При использовании конечной точки Azure AD:

• Если ваше приложение является мультитенантным, необходимо явно настроить его на мультитенантность на портале Azure.
• Нет конечной точки согласия администратора ( / adminconsent ). Вместо этого ваше приложение может запросить согласие администратора во время выполнения, добавив параметр prompt = admin_consent в запрос авторизации. Дополнительные сведения см. В разделе Запуск платформы согласия Azure AD во время выполнения статьи Интеграция приложений с Azure Active Directory.
• Параметры в запросах авторизации и токена различаются. Например, в запросах конечной точки Azure AD нет параметра scope ; вместо этого ресурс параметр используется для указания URI ресурса ( resource = https: // graph.microsoft.com ), для которой запрашивается авторизация (с согласия администратора) или токен.

Вы можете дополнительно изучить этот сценарий с помощью следующих ресурсов:

• Для получения информации об использовании платформы Microsoft Identity с различными типами приложений см. Ссылки Начало работы в документации по платформе Microsoft Identity. В руководстве содержатся ссылки на обзорные темы, краткие руководства, учебные пособия, образцы кода и документацию по протоколам для различных типов приложений, поддерживаемых платформой Microsoft Identity.
• Для получения информации о библиотеке аутентификации Microsoft (MSAL) и промежуточном программном обеспечении сервера, доступном для использования с конечной точкой платформы идентификации Microsoft, см. Библиотеки аутентификации Microsoft.

См. Также

Аутентификация OAuth3 для доступа к API

OAuth3 — предпочтительный метод аутентификации доступа к API. OAuth3 разрешает авторизацию без получения внешним приложением адреса электронной почты или пароля пользователя. Вместо этого внешнее приложение получает токен, который разрешает доступ к учетной записи пользователя.Пользователь может отозвать токен для одного приложения, не влияя на доступ любого другого приложения.

Регистрация приложения

Внешнее приложение должно быть зарегистрировано в Aha! прежде чем он сможет использовать OAuth3 для аутентификации пользователей.

Зарегистрированное приложение могут использовать все пользователей Aha !, а не только пользователи учетной записи лица, регистрирующего приложение. Однако зарегистрированные приложения невозможно обнаружить — простая регистрация вашего приложения не сделает его видимым для других Aha! пользователи (даже пользователи вашей учетной записи) — вы можете опубликовать свое приложение.

Зарегистрируйте свое приложение

После регистрации приложения вы можете использовать идентификатор клиента , секрет клиента и URL перенаправления в потоке авторизации.

Процесс авторизации

Чтобы авторизовать внешнее приложение для аутентификации в качестве пользователя, приложение использует перенаправления браузера для отправки пользователя в Aha !. Ага! поддерживает поток кода авторизации OAuth3 (подходит для серверных приложений) и неявный поток предоставления (подходит для приложений на основе браузера).

Перенаправить пользователя для запроса доступа

Пользователь должен быть перенаправлен в своем браузере на URL-адрес авторизации OAuth3, передав параметры приложения:

GET https: // .aha.io / oauth / authorize

Ага! перенаправляет пользователя обратно в приложение

После того, как пользователь авторизует приложение, его браузер будет перенаправлен обратно на redirect_uri .

Если используется неявный поток предоставления, то URL-адрес, на который перенаправляется пользователь, будет включать параметр с именем access_token , который является значением токена доступа, который можно напрямую использовать с API.

Если используется поток кода авторизации, то Ага! будет включать параметр в URL-адрес с именем , код , который необходимо заменить на токен доступа, сделав еще один запрос к Aha! на следующем этапе.

Это перенаправление также будет включать параметр account_subdomain . Если пользователь был отправлен на secure.aha.io в начале потока, этот параметр содержит поддомен учетной записи этого пользователя. Вы можете использовать этот поддомен для потока токенов доступа запроса ниже или для выполнения запросов API.

Запросить токен доступа

Приложение обменивает код из предыдущего шага на токен доступа. На этом этапе приложение использует свой секрет, который обеспечивает дополнительный уровень безопасности, поскольку Aha! можно быть уверенным, что это авторизованное приложение, которое делает запрос от имени пользователя.

POST https: // .aha.io / oauth / token

Параметры

Например:

  завиток "https://mydomain.aha.io/oauth/token" -X POST --data «client_id = a73bbb264c7432421b9abc05fae6bf9379b9fb49bbefdf84ab036487fd5b & client_secret = 467b9a301fedac887a46a23d3f29d76afdff30ac9bbf6c8c и код = 10dbffca01ce6985868b4cee84e0444f5bcdda104b60a13038c1d74b72e6797f & grant_type = authorization_code & redirect_uri = HTTP: // ГЛЖ .me / app_callback.html " 

Ответом на этот POST-запрос будет строка JSON, содержащая токен доступа, который затем можно использовать для доступа к API:

  
 {
" access_token ":" 1d08ddc8c781ca1afd75ffbec12870aee "90d75ffbec0870aea56 token_type ":" bearer "
}  

Передовые методы аутентификации учетной записи и управления паролями

Обновлено для 2021 года : В этот пост включены обновленные передовые практики, включая последние из технических документов Google Best Practices for Password Management для пользователей и разработчиков системы rs.

Управление учетными записями, аутентификация и управление паролями могут быть сложными. Часто управление учетными записями - это темный угол, который не является главным приоритетом для разработчиков или менеджеров по продукту. Получающийся в результате опыт часто не соответствует тому, что некоторые из ваших пользователей ожидали бы в отношении безопасности данных и удобства использования.

К счастью, Google Cloud предлагает несколько инструментов, которые помогут вам принимать правильные решения в отношении создания, безопасной обработки и аутентификации учетных записей пользователей (в данном контексте всех, кто идентифицирует себя для вашей системы - клиентов или внутренних пользователей).Независимо от того, отвечаете ли вы за веб-сайт, размещенный в Google Kubernetes Engine, API на Apigee, приложение, использующее Firebase, или другой сервис с аутентифицированными пользователями, в этом посте излагаются передовые методы, которым необходимо следовать, чтобы обеспечить безопасность, масштабируемость и удобство использования. система аутентификации аккаунта.

1. Хешируйте эти пароли

Мое самое важное правило для управления учетными записями - безопасно хранить конфиденциальную информацию о пользователях, включая их пароли. Вы должны относиться к этим данным как к священным и обращаться с ними надлежащим образом.

Ни при каких обстоятельствах не храните пароли в виде открытого текста. Вместо этого ваша служба должна хранить криптографически стойкий хэш пароля, который нельзя отменить, - созданный с помощью Argon2id или Scrypt. Хэш должен иметь значение, уникальное для этих конкретных учетных данных. Не используйте устаревшие технологии хеширования, такие как MD5, SHA1, и ни при каких обстоятельствах не должны использовать обратимое шифрование или пытаться изобрести собственный алгоритм хеширования. Используйте перец, который не хранится в базе данных, чтобы дополнительно защитить данные в случае взлома.Рассмотрим преимущества многократного повторного хеширования пароля.

Спроектируйте свою систему так, чтобы в конечном итоге она была взломана. Спросите себя: «Если бы моя база данных была украдена сегодня, была бы угроза безопасности моих пользователей для моей службы или других служб, которые они используют?» А также «Что мы можем сделать, чтобы снизить вероятность повреждения в случае утечки?»

Еще один момент: если вы могли бы создать пароль пользователя в виде открытого текста в любое время за пределами времени, сразу после того, как они предоставили его вам, это проблема с вашей реализацией.

Если ваша система требует обнаружения почти повторяющихся паролей, таких как изменение «Пароль» на «pAssword1», сохраните хэши общих вариантов, которые вы хотите заблокировать, с нормализованными и преобразованными в нижний регистр всеми буквами. Это можно сделать при создании пароля или при успешном входе в уже существующие учетные записи. Когда пользователь создает новый пароль, сгенерируйте варианты того же типа и сравните хэши с хешами из предыдущих паролей. Используйте тот же уровень безопасности хеширования, что и для фактического пароля.

2. Разрешить сторонним поставщикам удостоверений, если это возможно.

Сторонние поставщики удостоверений позволяют полагаться на надежную внешнюю службу для проверки подлинности пользователя. Обычно используемые провайдеры - это Google, Facebook и Twitter.

Вы можете реализовать внешних поставщиков удостоверений наряду с существующей внутренней системой проверки подлинности, используя такую ​​платформу, как Identity Platform. Identity Platform дает ряд преимуществ, включая более простое администрирование, меньшую поверхность атаки и многоплатформенный SDK.Мы коснемся других преимуществ в этом списке.

3. Разделите понятие идентификатора пользователя и учетной записи пользователя

Ваши пользователи не являются адресами электронной почты. Это не номер телефона. Это даже не уникальное имя пользователя. Любой из этих факторов аутентификации должен быть изменен без изменения содержимого или личной информации (PII) в учетной записи. Ваши пользователи - это многомерная кульминация их уникальных, персонализированных данных и опыта работы с вашим сервисом, а не сумма их учетных данных.Хорошо спроектированная система управления пользователями имеет низкую взаимосвязь и высокую степень согласованности между различными частями профиля пользователя.

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

4. Разрешить нескольким идентификаторам связываться с одной учетной записью пользователя

Пользователь, который аутентифицируется в вашей службе, используя свое имя пользователя и пароль в течение одной недели, может выбрать Google Sign-In на следующей неделе, не понимая, что это может создать дублирующую учетную запись. Точно так же у пользователя может быть очень веская причина связать несколько адресов электронной почты с вашим сервисом. Если вы правильно разделили идентификацию пользователя и аутентификацию, будет несложно связать несколько методов аутентификации с одним пользователем.

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

5. Не блокируйте длинные или сложные пароли

NIST публикует рекомендации по сложности и надежности паролей. Поскольку вы используете (или очень скоро будете) использовать надежный криптографический хеш для хранения паролей, многие проблемы решены за вас. Хеши всегда будут давать на выходе фиксированную длину, независимо от длины ввода, поэтому ваши пользователи должны иметь возможность использовать пароли столько, сколько захотят. Если вы должны ограничить длину пароля, сделайте это в зависимости от ограничений вашей инфраструктуры; часто это вопрос использования памяти (память, используемая для каждой операции входа в систему * потенциальные одновременные входы в систему на машину) или, что более вероятно, максимального размера POST, допустимого вашими серверами.Мы говорим о цифрах от сотен КБ до более 1 МБ. Шутки в сторону. Ваше приложение уже должно быть усилено, чтобы предотвратить злоупотребление большими входными данными. Это не создает новых возможностей для злоупотреблений, если вы используете элементы управления для предотвращения заполнения учетных данных и хешируете ввод как можно скорее, чтобы освободить память.

Ваши хешированные пароли, скорее всего, уже будут состоять из небольшого набора символов ASCII. Если нет, вы можете легко преобразовать двоичный хеш в Base64. Имея это в виду, вы должны разрешить своим пользователям использовать в пароле буквально любые символы, которые они пожелают.Если кому-то нужен пароль, состоящий из клингонских, эмодзи и ASCII-артов с пробелами на обоих концах, у вас не должно быть технических причин для отказа. Просто не забудьте выполнить нормализацию Unicode, чтобы обеспечить кроссплатформенную совместимость. См. Нашу техническую документацию для разработчиков системы (PDF) для получения дополнительной информации о Unicode и поддерживаемых символах в паролях.

Любой пользователь, пытающийся использовать экстремальный пароль, вероятно, следует передовым методам работы с паролями (PDF), включая использование диспетчера паролей, который позволяет вводить сложные пароли даже на ограниченных клавиатурах мобильных устройств.Если пользователь может ввести строку в первую очередь (т. Е. Спецификация HTML для ввода пароля запрещает перевод строки и возврат каретки), пароль должен быть приемлемым.

6. Не навязывайте необоснованные правила для имен пользователей

Для сайта или службы небезосновательно требовать имена пользователей длиннее двух или трех символов, блокировать скрытые символы и предотвращать использование пробелов в начале и конце имени пользователя. Однако некоторые сайты выходят за рамки требований, таких как минимальная длина восьми символов или блокировка любых символов, кроме 7-битных букв и цифр ASCII.

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

В некоторых случаях лучше всего назначать имена пользователей. Если это так для вашей службы, убедитесь, что назначенное имя пользователя является удобным для пользователя, поскольку им необходимо его вспомнить и сообщить. В буквенно-цифровых идентификаторах следует избегать визуально неоднозначных символов, таких как «Il1O0». Вам также рекомендуется выполнить сканирование словаря для любой случайно сгенерированной строки, чтобы убедиться, что в имя пользователя нет нежелательных сообщений.Эти же правила применимы и к автоматически сгенерированным паролям.

7. Подтвердите личность пользователя

Если вы запрашиваете у пользователя контактную информацию, вам следует как можно скорее подтвердить этот контакт. Отправьте код подтверждения или ссылку на адрес электронной почты или номер телефона. В противном случае пользователи могут сделать опечатку в своих контактных данных, а затем потратить значительное время на использование вашего сервиса только для того, чтобы обнаружить, что при следующей попытке входа в систему нет учетной записи, соответствующей их информации. Эти учетные записи часто становятся сиротами и не подлежат восстановлению без ручного вмешательства.Что еще хуже, контактная информация может принадлежать кому-то другому, передавая полный контроль над учетной записью третьей стороне.

8. Разрешить пользователям изменять свое имя пользователя

Это удивительно часто встречается в устаревших системах или на любой платформе, которая предоставляет учетные записи электронной почты, чтобы пользователи не могли изменять свое имя пользователя. Есть очень веские причины не выдавать автоматически имена пользователей для повторного использования, но у постоянных пользователей вашей системы в конечном итоге появятся веские причины использовать другое имя пользователя, и они, вероятно, не захотят создавать новую учетную запись.

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

Если вы работаете с унаследованной архитектурой, соблюдение этой передовой практики может быть очень трудным. Даже у таких компаний, как Google, есть технические препятствия, которые делают это труднее, чем может показаться. При разработке новых систем приложите все усилия, чтобы разделить концепцию удостоверения пользователя и учетной записи пользователя и позволить нескольким удостоверениям связываться с одной учетной записью пользователя, и это будет гораздо меньшей проблемой. Независимо от того, работаете ли вы над существующим кодом или с новым кодом, выберите правильные правила для своей организации с упором на то, чтобы ваши пользователи могли расти и меняться с течением времени.

9. Разрешите пользователям удалять свои учетные записи.

Удивительно, но количество служб не имеет средств самообслуживания для удаления пользователем своей учетной записи и связанной с ней PII. В зависимости от характера вашей службы это может включать или не включать созданный ими общедоступный контент, такой как публикации и загрузки. У пользователя есть ряд веских причин навсегда закрыть учетную запись и удалить всю свою PII. Эти проблемы должны быть сбалансированы с учетом вашего пользовательского опыта, требований безопасности и соответствия требованиям.Многие, если не большинство систем, работают под каким-либо нормативным контролем (например, PCI или GDPR), который предоставляет конкретные рекомендации по хранению данных, по крайней мере, для некоторых пользовательских данных. Распространенное решение, позволяющее избежать проблем с соблюдением нормативных требований и ограничить возможность утечки данных, - позволить пользователям запланировать автоматическое удаление своей учетной записи в будущем.

В некоторых случаях от вас может потребоваться по закону выполнить запрос пользователя на своевременное удаление его PII. Вы также значительно увеличиваете свою уязвимость в случае утечки данных из «закрытых» учетных записей.

10. Примите осознанное решение о длине сеанса

Часто упускаемый из виду аспект безопасности и аутентификации - это продолжительность сеанса. Google прилагает много усилий для обеспечения того, чтобы пользователи были такими, какими они себя называют, и будет перепроверять их на основе определенных событий или поведения. Пользователи могут предпринять шаги для дальнейшего повышения своей безопасности.

У вашей службы может быть веская причина держать сеанс открытым на неопределенный срок для некритических аналитических целей, но должны быть пороговые значения, после которых вы запрашиваете пароль, 2-й фактор или другую проверку пользователя.

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

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

11. Использование двухэтапной аутентификации

Рассмотрите практические последствия кражи учетной записи для пользователя при выборе методов двухэтапной аутентификации (также известной как двухфакторная аутентификация, MFA или 2FA).Одноразовые пароли на основе времени (TOTP), коды подтверждения электронной почты или «волшебные ссылки» удобны для потребителей и относительно безопасны. SMS-аутентификация с двухфакторной аутентификацией устарела NIST из-за множества недостатков, но это может быть наиболее безопасным вариантом, который ваши пользователи примут за то, что они считают тривиальной услугой.

Предложите наиболее безопасную двухфакторную аутентификацию, какую только можете. Аппаратная двухфакторная аутентификация, такая как Titan Security Key, идеально подходит для вашего приложения, если это возможно. Даже если библиотека TOTP недоступна для вашего приложения, проверка электронной почты или двухфакторная аутентификация, предоставляемые сторонними поставщиками удостоверений, являются простым средством повышения вашей безопасности без больших затрат и усилий.Просто помните, что безопасность ваших учетных записей зависит от самого слабого метода 2FA или восстановления учетной записи.

12. Сделайте идентификаторы пользователей нечувствительными к регистру.

Вашим пользователям все равно, и они могут даже не помнить точный регистр своего имени пользователя. Имена пользователей должны быть полностью нечувствительными к регистру. Хранить имена пользователей и адреса электронной почты в нижнем регистре и преобразовывать любой ввод в нижний регистр перед сравнением - тривиальная задача. Обязательно укажите языковой стандарт или используйте нормализацию Unicode для любых преобразований.

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

13. Создайте безопасную систему аутентификации

Если вы используете такую ​​службу, как Identity Platform, многие проблемы безопасности решаются автоматически.Тем не менее, ваша служба всегда должна быть спроектирована должным образом, чтобы предотвратить злоупотребления. Основные соображения включают реализацию сброса пароля вместо получения пароля, подробное ведение журнала активности учетной записи, ограничение скорости попыток входа в систему для предотвращения заполнения учетных данных, блокировку учетных записей после слишком большого количества неудачных попыток входа в систему и требование двухфакторной аутентификации для нераспознанных устройств или учетных записей, которые имеют простаивали в течение длительного времени. У безопасной системы аутентификации есть еще много аспектов, поэтому, пожалуйста, обратитесь к разделу для дальнейшего чтения ниже, чтобы найти ссылки на дополнительную информацию.

Дополнительная литература

Существует ряд отличных ресурсов, которые помогут вам в процессе разработки, обновления или миграции вашей учетной записи и системы управления аутентификацией. Я рекомендую в качестве отправной точки следующее:

Аутентификация конечного пользователя с помощью OAuth 2.0 - OAuth

Аутентификация пользователя с помощью OAuth 2.0

Спецификация OAuth 2.0 определяет протокол делегирования , который полезен для передачи решений об авторизации по сети веб-приложений и API.OAuth используется в самых разных приложениях, включая механизмы аутентификации пользователей. Это привело к тому, что многие разработчики и поставщики API ошибочно пришли к выводу, что OAuth сам по себе является протоколом аутентификации , и ошибочно использовали его как таковой. Скажем еще раз, чтобы было ясно:

OAuth 2.0 не является протоколом аутентификации.

Большая часть путаницы возникает из-за того, что OAuth используется внутри протоколов аутентификации, и разработчики будут видеть компоненты OAuth и взаимодействовать с потоком OAuth и предполагать, что, просто используя OAuth, они могут выполнить аутентификацию пользователя.Это оказывается не только неправдой, но и опасно для поставщиков услуг, разработчиков и конечных пользователей.

Эта статья предназначена для помощи потенциальным провайдерам идентификации с вопросом о том, как создать API аутентификации и идентификации, используя OAuth 2.0 в качестве основы. По сути, если вы говорите: «У меня есть OAuth 2.0, и мне нужны аутентификация и идентификация», то читайте дальше.

Что такое аутентификация?

Аутентификация в контексте доступа пользователя к приложению сообщает приложению , кто текущий пользователь и присутствуют ли они.Протокол полной аутентификации, вероятно, также сообщит вам ряд атрибутов об этом пользователе, таких как уникальный идентификатор, адрес электронной почты и как их называть, когда приложение говорит «Доброе утро». Аутентификация - это все, что касается пользователя и его присутствия в приложении, и протокол аутентификации в масштабе Интернета должен иметь возможность делать это через границы сети и безопасности.

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

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

Однако оказывается, что есть несколько вещей, которые можно использовать вместе с OAuth, чтобы создать протокол аутентификации и идентификации поверх этого протокола делегирования и авторизации. Почти во всех этих случаях основная функциональность OAuth остается неизменной, и происходит то, что пользователь делегирует доступ к своему идентификатору приложению, в которое он пытается войти. Затем клиентское приложение становится потребителем API идентификации, тем самым выясняя, кто первым авторизовал клиента.Одним из основных преимуществ создания аутентификации поверх авторизации таким образом является то, что она позволяет управлять согласием конечного пользователя, что очень важно для междоменной федерации удостоверений в масштабе Интернета. Еще одно важное преимущество заключается в том, что пользователь может одновременно делегировать доступ к другим защищенным API наряду с их идентификаторами, что значительно упрощает управление как разработчикам приложений, так и конечным пользователям. С помощью одного вызова приложение может узнать, вошел ли пользователь в систему, что приложение должно вызывать пользователя, загружать фотографии для печати и публиковать обновления в своем потоке сообщений.Эта простота очень убедительна, но, выполняя обе функции одновременно, многие разработчики объединяют две функции.

Аутентификация против авторизации: метафора

Чтобы прояснить ситуацию, может быть полезно подумать о проблеме в терминах метафоры: шоколад против помадки. С самого начала природа этих двух вещей совершенно разная: шоколад - это ингредиент, помадка - это кондитерское изделие. Из шоколада можно делать много разных вещей, и его даже можно использовать сам по себе.Фадж может быть сделан из самых разных вещей, и одна из этих вещей может быть шоколадом , но для приготовления помадки требуется более одного ингредиента, и это может даже не включать шоколад. Таким образом, неверно утверждать, что шоколадный равен шоколадной помаде , и, безусловно, будет преувеличением сказать, что шоколадный равен шоколадной помаде .

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

И на самом деле, существует ряд хорошо известных рецептов, как это можно сделать с конкретными поставщиками, такими как Facebook Connect, Sign In With Twitter и OpenID Connect (который, среди прочего, поддерживает систему входа Google).Каждый из этих рецептов добавляет в OAuth ряд элементов, например API общего профиля, для создания протокола аутентификации. Можете ли вы создать протокол аутентификации без OAuth? Конечно, существует множество видов помадки, равно как и множество видов нешоколадной помадки. Но сегодня мы хотим поговорить об аутентификации, построенной на основе OAuth 2.0, о том, что может пойти не так и как сделать это безопасным и вкусным.

Распространенные ошибки аутентификации с использованием OAuth

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

Жетоны доступа как доказательство аутентификации

Так как аутентификация обычно происходит перед выдачей токена доступа, заманчиво рассматривать получение токена доступа любого типа как доказательство того, что такая аутентификация произошла.Однако простое владение токеном доступа само по себе ничего не говорит клиенту. В OAuth маркер спроектирован так, чтобы быть непрозрачным для клиента, но в контексте аутентификации пользователя клиент должен иметь возможность извлекать некоторую информацию из маркера.

Эта проблема возникает из-за того, что клиент не является предполагаемой аудиторией маркера доступа OAuth. Вместо этого это авторизованный презентатор этого токена, а аудитория фактически является защищенным ресурсом.Защищенный ресурс обычно не в состоянии определить, присутствует ли пользователь по-прежнему только по токену, поскольку по самой природе и конструкции протокола OAuth пользователь не будет доступен при соединении между клиентом и защищенным ресурс. Чтобы противостоять этому, должен быть артефакт, направленный на самого клиента. Это может быть сделано путем двойного назначения токена доступа, определения формата, который клиент может проанализировать и понять. Однако, поскольку общий OAuth не определяет конкретный формат или структуру для самого токена доступа, протоколы, такие как идентификатор идентификатора OpenID Connect и подписанный ответ Facebook Connect, предоставляют дополнительный токен вместе с токеном доступа, который передает информацию аутентификации непосредственно клиенту.Это позволяет основному токену доступа оставаться непрозрачным для клиента, как и в обычном OAuth.

Доступ к защищенному API как доказательство аутентификации

Поскольку токен доступа можно обменять на набор атрибутов пользователя, возникает соблазн думать, что наличия действительного токена доступа достаточно, чтобы доказать, что пользователь аутентифицирован. Это предположение оказывается верным в некоторых случаях, когда токен был недавно отчеканен в контексте аутентификации пользователя на сервере авторизации.Однако это не единственный способ получить токен доступа в OAuth. Токены обновления и утверждения могут использоваться для получения токенов доступа без присутствия пользователя, а в некоторых случаях предоставление доступа может происходить без необходимости аутентификации пользователя вообще.

Кроме того, маркер доступа обычно можно использовать еще долго после того, как пользователь больше не присутствует. Помните, поскольку OAuth является протоколом делегирования, это фундаментально для его конструкции. Это означает, что если клиент хочет убедиться, что аутентификация по-прежнему действительна, недостаточно просто снова обменять токен на атрибуты пользователя, потому что защищенный OAuth ресурс, API идентификации, часто не может определить, является ли пользователь есть или нет.

Внедрение токенов доступа

Дополнительная (и очень опасная) угроза возникает, когда клиенты принимают токены доступа из источников, отличных от обратного вызова от конечной точки токена. Это может произойти для клиента, который использует неявный поток (где токен передается непосредственно в качестве параметра в хэше URL-адреса) и неправильно использует параметр состояния OAuth . Эта проблема также может возникнуть, если разные части приложения передают маркер доступа между компонентами, чтобы «совместно использовать» доступ между ними.Это проблематично, потому что это открывает место для токенов доступа, которые потенциально могут быть введены в приложение внешней стороной (и потенциально могут просочиться за пределы приложения). Если клиентское приложение не проверяет токен доступа с помощью какого-либо механизма, у него нет возможности отличить действительный токен от токена атаки.

Это можно смягчить, используя поток кода авторизации и принимая только токены непосредственно от enpdoint токена сервера авторизации, а также используя значение состояния , которое злоумышленник не может определить.

Отсутствие ограничения аудитории

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

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

Внедрение неверной информации о пользователе

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

Различные протоколы для каждого потенциального поставщика удостоверений

Одна из самых больших проблем с API идентификации на основе OAuth заключается в том, что даже при использовании полностью совместимого со стандартами механизма OAuth разные поставщики неизбежно будут реализовывать детали фактического API идентификации по-разному. Например, идентификатор пользователя может быть найден в поле user_id у одного провайдера, но в поле subject у другого провайдера. Несмотря на то, что они семантически эквивалентны, для их обработки потребуются два отдельных пути кода.Другими словами, хотя авторизация может происходить одинаково у каждого провайдера, передача информации аутентификации может быть разной. Эта проблема может быть смягчена поставщиками, использующими стандартный протокол аутентификации , построенный на основе OAuth, так что независимо от того, откуда исходит идентификационная информация, она передается одинаково.

Эта проблема возникает из-за того, что обсуждаемые здесь механизмы передачи аутентификационной информации явно не входят в область действия OAuth.OAuth не определяет конкретный формат токена, не определяет общий набор областей для токена доступа и вообще не обращается к тому, как защищенный ресурс проверяет токен доступа.

Стандарт для аутентификации пользователей с использованием OAuth: OpenID Connect

OpenID Connect - это открытый стандарт, опубликованный в начале 2014 года, который определяет способ взаимодействия с OAuth 2.0 для аутентификации пользователей. По сути, это широко опубликованный рецепт шоколадной помадки , который был опробован и протестирован большим количеством экспертов.Вместо того, чтобы создавать разные протоколы для каждого потенциального поставщика удостоверений, приложение может использовать один протокол для любого количества поставщиков, с которыми они хотят работать. Поскольку это открытый стандарт, OpenID Connect может быть реализован кем угодно без ограничений или проблем интеллектуальной собственности.

OpenID Connect построен непосредственно на OAuth 2.0 и в большинстве случаев развертывается вместе с инфраструктурой OAuth (или поверх нее). OpenID Connect также использует набор спецификаций JSON Object Signing And Encryption (JOSE) для передачи подписанной и зашифрованной информации в разных местах.Фактически, развертывание OAuth 2.0 с возможностями JOSE - это уже долгий путь к определению полностью совместимой системы OpenID Connect, и разница между ними относительно мала. Но эта дельта имеет большое значение, и OpenID Connect удается избежать многих ошибок, описанных выше, путем добавления нескольких ключевых компонентов в базу OAuth:

ID жетонов

Токен идентификатора OpenID Connect - это подписанный веб-токен JSON (JWT), который предоставляется клиентскому приложению вместе с обычным токеном доступа OAuth.Идентификационный токен содержит набор утверждений о сеансе аутентификации, включая идентификатор пользователя ( sub ), идентификатор поставщика удостоверений, выпустившего токен ( iss ), и идентификатор клиента, для которого это токен был создан ( aud ). Кроме того, ID Token содержит информацию о действительном (и обычно коротком) времени жизни токена, а также любую информацию о контексте аутентификации, которая должна быть передана клиенту, например, как давно пользователю был представлен первичный механизм аутентификации.Поскольку формат идентификатора токена известен клиенту, он может анализировать содержимое токена напрямую и получать эту информацию, не полагаясь для этого на внешнюю службу. Кроме того, он выдается в дополнение (а не вместо) токена доступа, позволяя токену доступа оставаться непрозрачным для клиента, как это определено в обычном OAuth. Наконец, сам токен подписывается закрытым ключом поставщика удостоверений, добавляя дополнительный уровень защиты к утверждениям внутри него в дополнение к транспортной защите TLS, которая использовалась в первую очередь для получения токена, предотвращая класс олицетворения. атаки.Применяя несколько простых проверок к этому токену идентификатора, клиент может защитить себя от большого количества распространенных атак.

Поскольку токен ID подписан сервером авторизации, он также предоставляет место для добавления отдельных подписей к коду авторизации ( c_hash ) и токену доступа ( at_hash ). Эти хэши могут быть проверены клиентом, сохраняя при этом код авторизации и содержимое токена доступа непрозрачными для клиента, предотвращая целый класс атак с использованием инъекций.

Конечная точка UserInfo

Следует отметить, что клиентам не требуется использовать токен доступа, так как ID Token содержит всю необходимую информацию для обработки события аутентификации. Однако для обеспечения совместимости с OAuth и соответствия общей тенденции параллельной авторизации удостоверений и другого доступа к API OpenID Connect всегда выдает токен ID вместе с токеном доступа OAuth.

В дополнение к утверждениям в идентификаторе идентификатора OpenID Connect определяет стандартный защищенный ресурс, который содержит утверждения о текущем пользователе.Заявления здесь не являются частью процесса аутентификации, как обсуждалось выше, а вместо этого предоставляют связанные атрибуты идентификации, которые делают протокол аутентификации более ценным для разработчиков приложений. В конце концов, лучше сказать «Доброе утро, Джейн Доу» вместо «Доброе утро, 9XE3-JI34-00132A». OpenID Connect определяет набор стандартизованных областей действия OAuth, которые сопоставляются с подмножествами этих атрибутов: профиль , электронная почта , телефон и адрес , что позволяет простым запросам авторизации OAuth нести необходимую информацию для запроса.OpenID Connect определяет специальную область openid , которая включает выдачу токена ID, а также доступ к конечной точке UserInfo по токену доступа. Области OpenID Connect могут использоваться вместе с другими областями OAuth, отличными от OpenID-Connect, без конфликтов, а выданный токен доступа потенциально может быть нацелен на несколько различных защищенных ресурсов. Это позволяет системе идентификации OpenID Connect плавно сосуществовать с системой авторизации OAuth.

Динамическое обнаружение серверов и регистрация клиентов

OAuth 2.0 был написан для обеспечения множества различных развертываний, но по замыслу не указывает, как эти развертывания должны быть настроены или как компоненты узнают друг о друге. Это нормально в обычном мире OAuth, где один сервер авторизации защищает определенный API, а два тесно связаны. С помощью OpenID Connect общий защищенный API развертывается для самых разных клиентов и поставщиков, каждый из которых должен знать друг о друге для работы. Было бы не масштабируемо для каждого клиента заранее знать каждого поставщика, и было бы еще менее масштабируемым требовать, чтобы каждый поставщик знал о каждом потенциальном клиенте.

Чтобы противодействовать этому, OpenID Connect определяет протокол обнаружения, который позволяет клиентам легко получать информацию о том, как взаимодействовать с определенным поставщиком удостоверений. На другой стороне транзакции OpenID Connect определяет протокол регистрации клиентов, который позволяет знакомить клиентов с новыми поставщиками удостоверений. Используя эти два механизма и общий API идентификации, OpenID Connect может функционировать в масштабе Интернета, когда никакие стороны не должны знать друг о друге заранее.

Совместимость с OAuth 2.0

Даже при всей этой надежной возможности аутентификации OpenID Connect (по замыслу) по-прежнему совместим с обычным OAuth 2.0, что делает его очень хорошим выбором для развертывания поверх системы OAuth с минимальными усилиями разработчика. Фактически, если служба уже использует OAuth и спецификации JSON Object Signing and Encryption (JOSE) (включая JWT), эта служба уже находится на пути к поддержке OpenID Connect.

Чтобы облегчить создание хороших клиентских приложений, рабочая группа OpenID Connect опубликовала документы по созданию базового клиента OpenID Connect с использованием потока кода авторизации, а также по созданию неявного клиента OpenID Connect.Оба этих документа проводят разработчика через создание базового клиента OAuth 2.0 и добавление нескольких компонентов, необходимых для OpenID Connect.

Расширенные возможности

Хотя основная спецификация довольно проста, не все варианты использования могут быть адекватно решены с помощью базовых механизмов. Для поддержки расширенных вариантов использования, включая развертывание с более высоким уровнем безопасности, OpenID Connect также определяет ряд дополнительных расширенных возможностей помимо стандартного OAuth, включая следующие (среди прочего):

Дополнительная литература

• В статье OAuth 2.0 и входа в систему, Витторио Берточчи подробно описывает границы безопасности между сторонами и объясняет, почему уровень авторизации имеет смысл в качестве нижнего уровня, над которым нужно строить, и предоставляет источник украденной выше метафоры шоколад против помадки.
• Джастин Ричер представил подробный обзор задействованных здесь технологий и их взаимосвязи в Auth * In the Extended Enterprise в Массачусетском технологическом институте.
• Джон Брэдли написал серию статей по этой теме, в том числе:

Эта статья написана Джастином Ричером при участии сообщества OAuth.
и находится под лицензией Creative Commons Attribution 4.0 Международная лицензия.

Аутентификация против авторизации | Okta

Аутентификация и авторизация могут казаться похожими, но это разные процессы безопасности в мире управления идентификацией и доступом (IAM).

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

Что такое аутентификация?

Аутентификация - это проверка того, что пользователи являются теми, кем они себя называют.Это первый шаг в любом процессе обеспечения безопасности.

Завершите процесс аутентификации с помощью:

• Пароли. Имена пользователей и пароли - наиболее распространенные факторы аутентификации. Если пользователь вводит правильные данные, система предполагает, что личность действительна, и предоставляет доступ.
• Одноразовые штифты . Разрешить доступ только для одного сеанса или транзакции.
• Приложения для аутентификации. Генерировать коды безопасности через внешнюю сторону, предоставляющую доступ.
• Биометрия . Пользователь представляет отпечаток пальца или скан глаз, чтобы получить доступ к системе.

В некоторых случаях системы требуют успешной проверки более чем одного фактора перед предоставлением доступа. Это требование многофакторной аутентификации (MFA) часто используется для повышения безопасности, превышающего то, что могут обеспечить только пароли.

Что такое авторизация?

Авторизация в системе безопасности - это процесс предоставления пользователю разрешения на доступ к определенному ресурсу или функции.Этот термин часто используется как синоним контроля доступа или привилегий клиента.

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

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

Аутентификация и авторизация

Несмотря на похожие термины, аутентификация и авторизация - это отдельные шаги в процессе входа в систему. Понимание разницы между ними является ключом к успешной реализации решения IAM.

Давайте воспользуемся аналогией, чтобы обозначить различия.

Представьте себе человека, который подходит к запертой двери, чтобы позаботиться о домашнем животном, пока семья уезжает в отпуск. Этому человеку нужно:

• Аутентификация , в виде ключа.Замок на двери предоставляет доступ только тем, у кого есть правильный ключ, почти так же, как система предоставляет доступ только тем пользователям, у которых есть правильные учетные данные.
• Авторизация, в виде разрешений. Оказавшись внутри, человек имеет право войти на кухню и открыть шкаф, в котором хранится корм для домашних животных. У человека может не быть разрешения пойти в спальню, чтобы быстро вздремнуть.

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

Системы

реализуют эти концепции таким же образом, поэтому крайне важно, чтобы администраторы IAM понимали, как использовать и то, и другое:

• Аутентификация. Разрешите каждому сотруднику получить доступ к системам вашего рабочего места, если они предоставят правильные учетные данные в соответствии с выбранными вами требованиями аутентификации.
• Авторизация. Разрешить доступ к файлам, относящимся к конкретному отделу, и при необходимости зарезервировать доступ к конфиденциальным данным, например к финансовой информации. Убедитесь, что у сотрудников есть доступ к файлам, которые им нужны для работы.

Поймите разницу между аутентификацией и авторизацией и внедрите решения IAM, которые имеют сильную поддержку обоих.Вы защитите свою организацию от утечки данных и позволите своим сотрудникам работать более продуктивно.

Предоставление разрешений с помощью Okta

Okta Lifecycle Management дает вам краткий обзор разрешений пользователей, что означает, что вы можете легко предоставлять и отзывать доступ к своим системам и инструментам по мере необходимости. Между тем, Okta Adaptive MFA позволяет защитить вашу инфраструктуру за счет выбора факторов аутентификации.