Успешная авторизация это что
Авторизация и регистрация: почему это две большие разницы
На смартфонах устанавливают приложения. И далее, не задумываясь, открывают их с помощью одного или двух тапов. Приложение готово к работе. Если же входить куда-либо через браузер на компьютере, ноутбуке или на смартфоне, то появляются две кнопки для входа пользователя: авторизация и регистрация. Какая между ними разница и почему их нельзя путать?
На некоторых сайтах, в электронной почте, в социальных сетях, в интернет банке, если их открыть через браузер на компьютере или смартфоне, обычно есть два варианта для входа. Первый вариант – это авторизация для «стареньких» пользователей, которые ранее прошли регистрацию. Второй вариант – это регистрация для «новеньких» людей, еще не зарегистрированных на данном ресурсе.
Что такое регистрация
Регистрация – это необходимый этап для того, чтобы пользователь получил доступ к тем возможностям, которые предоставляются на каком-либо интернет-ресурсе. Регистрацию проходят только один раз (в идеале). После того, как человек ее прошел, ему становятся доступны те возможности, которые имеются на данном ресурсе.
Как происходит регистрация? Когда пользователь первый раз где-либо регистрируется, то при этом, как правило, ему нужно придумать логин и пароль. Именно придумать, создать новый логин и к нему новый пароль.
В качестве логина может выступать либо адрес электронной почты, либо номер мобильного телефона, либо фамилия и имя, либо никнейм. Зачастую при регистрации есть важный момент: необходимо подтвердить свой Email, либо удостоверить свой номер смартфона.
Казалось бы, зачем такие сложности? Ведь для того, чтобы подтвердить свою почту, нужно ее открыть, найти там письмо для подтверждения или выполнить иные инструкции. На телефон в качестве подтверждения того факта, что номер принадлежит вам, приходит код для подтверждения, либо звонок-сброс, либо еще указание на какое-то необходимое действие.
Для чего все это, может, можно как-то попроще пройти регистрацию? Нет, потому что только таким образом можно доказать два необходимых факта. Во-первых, проверяется, что у вас есть доступ к почте или к телефону. Во-вторых, подтверждается, что вы правильно, без единой ошибки ввели адрес своей почты или номер своего мобильного.
Как подтвердить email-адрес или мобильный при регистрации
Допустим, при регистрации в качестве логина нужно ввести свой email-адрес. Как его подтвердить? Как уже отмечалось выше, нужно открыть свою почту и найти там письмо с того сайта, где вы проходите регистрацию. Письмо может прийти не сразу, а спустя несколько минут или более.
Кроме того, стоит проверить папку Спам в почте, письмо по ошибке могло попасть туда. Если же прошло достаточно времени, но письмо не удается найти, то, возможно, была допущена ошибка при вводе email. Стоит попробовать заново пройти регистрацию.
Если же письмо для подтверждения электронного адреса пришло, его нужно открыть и прочитать. Как правило, следует кликнуть по ссылке в этом письме. Этот клик по ссылке является доказательством того, что вы являетесь реальным пользователем почтового ящика.
Как быть, если при регистрации в качестве логина выступает номер смартфона? Как подтвердить мобильный? На телефон обычно приходит смс с кодом подтверждения или пуш-уведомление. При этом дается короткая и понятная инструкция, что необходимо сделать пользователю для подтверждения номера мобильного.
Для подтверждения номера мобильного иногда используется звонок-сброс. На него не нужно отвечать. Надо определить последние цифры в том номере, с которого звонят. Обычно следует ввести четыре последних цифры. Например, поступил звонок с номера +7 123 456 78 90. Тогда для подтверждения надо ввести код 7890.
Я рекомендую записать в блокнот, записную книжку и т.п. название сайта (приложения), логин и пароль, либо как-то иначе сохранить эти данные. Пароль чаще всего можно восстановить с помощью электронной почты или смартфона. Для этого на сайте может быть ссылка «Забыли пароль?».
А вот с логином сложнее, восстановить его в случае забывчивости удается далеко не всегда. В любом случае меньше стресса и потери времени будет, если есть возможность где-то у себя в записях найти свой логин и пароль.
Что означает повторная регистрация
Частенько бывает так, что пользователь либо забыл логин или пароль, либо не помнит и то, и другое вместе взятые. Также часто случается ситуация, когда человек уверен в том, что логин и пароль введены верно. Но при этом все равно появляется неприятная красная надпись: «Неверно введен логин или пароль».
В таких ситуациях стоит убедиться, что логин и пароль введены верно. О том, как можно это сделать, писала ЗДЕСЬ на примере соцсети Одноклассники. Описанные там приемы для проверки пароля или логина действуют для всех ситуаций.
Хороший выход в случае, когда забыт пароль, состоит в том, чтобы нажать на ссылку «Забыли пароль». Затем по предложенной инструкции можно попытаться восстановить пароль.
Однако некоторые пользователи не делают никаких попыток для восстановления прежних данных: логина или пароля. Они принимают решение о том, что нужно пройти новую регистрацию и проблема будет решена.
Проблема новой регистрации состоит в том, что пользователь становится «новеньким». Что это означает?
Помните, как в школе говорили, когда в класс приходил новый ученик: «У нас новенький (новенькая)!». При новой регистрации автоматически пропадут все накопленные ранее бонусы, баллы, подписки, купленные ранее билеты, курсы и прочие «плюшки», которые были «нажиты непосильным трудом». Придется начинать все по-новому, то есть, жизнь пойдет «с чистого листа». Придется опять зарабатывать карму, авторитет, бонусы, прочие преимущества старых клиентов сайта перед новыми.
Увы, при новой регистрации, как правило, уже нельзя восстановить те билеты, подписки, курсы, бонусы, баллы, которые хранились при прежней регистрации.
При новой регистрации вы автоматически становитесь «новеньким в интернет классе». Вероятно, это хорошо, если в «старом» классе были проблемы, карма была плохой и от нее необходимо избавляться. Но если все было хорошо, были заслуги в виде каких-то преимуществ (скидок, бонусов и прочего), то новая регистрация благополучно похоронит наработанные успехи и жизнь на сайте начнется все «с нуля».
Авторизация: вход после регистрации
Регистрацию проходят один раз. Потом для входа на какой-либо ресурс следует пользоваться кнопкой «Авторизация».
Авторизация на сайте или в приложении – это процесс, в котором ранее зарегистрированный пользователь вводит свой логин и пароль, чтобы система могла его опознать.
Слово «авторизация» произошло от английского authorization, что в переводе означает «авторизация», «полномочия», «разрешение».
Авторизация на каком-либо сайте (или интернет-ресурсе), по сути, означает «повторный вход» или «вход после регистрации». Если есть вход на сайт, то, вероятно, должен быть и выход. Но вот с выходом не все так однозначно, как со входом.
Выход: а что это такое
В современных приложениях на смартфоне сложно найти кнопку или значок для выхода, а зачастую это вообще невозможно. На компьютере обычно есть параметр «Выход», но многие пользователи никогда не используют эту возможность. Один раз зашли и больше никогда не выходят. Это хорошо, если техника всегда работает, никогда не подводит, либо не нужно заводить второй аккаунт на сайте.
Я думаю, что если есть возможность для выхода, то нужно этим пользоваться. Конечно, после выхода придется потом входить. То есть, нужно нажимать на кнопку «Авторизация», вводить логин и пароль.
Выход и последующий вход – это соблюдение безопасности в некотором роде, а также тренировка собственной памяти при вводе логина и пароля.
Рассмотрим примеры с кнопками для регистрации и авторизации для Яндекс.Почты, Yoomoney, РЖД, Ростелеком, Фейсбук, ВКонтакте. Приведенные примеры работают через браузер на компьютере или на смартфоне.
О приложениях на смартфоне здесь не упоминается. На телефоне устанавливается приложение, вводятся личные данные для регистрации или авторизации. И, как правило, на этом всё, потом уже не встречаются кнопки для регистрации или для авторизации.
Видео: Авторизация и регистрация, почему это две большие разницы
Яндекс Почта: Создать ID и Войти
В Яндекс.Почте кнопка «Создать ID» (цифра 1 на рис. 1) служит для регистрации нового почтового адреса (email). ID (читается «ай-ди») — это часть английского слова «identifier», что можно перевести как «идентификатор».
«Создать ID» означает, что нужно зарегистрировать, то есть создать новый логин и пароль для Яндекс.Почты. После того, как ID (логин и пароль) будет зарегистрирован, его можно использовать для того, чтобы пользоваться всей экосистемой Яндекса. Сервисов у Яндекса очень много, их количество постоянно пополняется.
Кнопка «Войти» (2 на рис. 1) предназначена для тех, кто уже один раз прошел регистрацию. В этом случае нужно ввести логин и пароль. После этого откроется почта с полученными письмами. Если же сделать новую почту с помощью «Создать ID», то там не будет тех писем, что были в старой почте.
Юмани: Создать кошелек и Войти
Юмани – это электронные деньги, которые ранее были Яндекс.Деньги. Потом сервис был приобретен Сбербанком и сменил название. Были Яндекс.Деньги, стали Юмани.
Кнопка «Создать кошелек» (цифра 1 на рисунке 2) означает появление нового кошелька, как правило, с нулевым балансом. Другая кнопка «Войти» (2 на рис. 3) позволяет войти в старый кошелек. Возможно, там уже есть рубли и накопленные баллы.
РЖД: Регистрация или Вход
РЖД является сокращением от «Российские Железные Дороги». Сайт РЖД предназначен для получения информации о поездах, расписании, наличии мест. Для приобретения билетов на поезд необходимо создать личный кабинет на сайте РЖД, он называется «Мои заказы».
Для создания личного кабинета РЖД, а также для входа в правом верхнем углу на сайте РЖД есть единая кнопка «Вход» (цифра 1 на рисунке 3). Кликнув по ней, появятся две вкладки «Вход» (3 на рис. 3) и «Регистрация» (2 на рис. 3).
Чтобы создать новый личный кабинет, следует нажать «Регистрация». В новом кабинете «Мои заказы» НЕ будет билетов, приобретенных ранее на сайте РЖД. После регистрации там можно будет только купить новый билет.
Для доступа к прежнему кабинету, надо использовать кнопку «Вход». Там можно найти билеты, приобретенные ранее на сайте РЖД, а также купить новые билеты.
Ростелеком личный кабинет: Зарегистрироваться и Войти
На сайте Ростелекома можно создать новый личный кабинет с помощью кнопки «Зарегистрироваться» (цифра 1 на рисунке 4). В личном кабинете можно проводить оплату, получать и тратить бонусы, писать запросы в техподдержку и т.д.
Если же личный кабинет уже был создан, следует ввести логин (или телефон, или почту, или лицевой счет) и пароль. После этого нажать на оранжевую кнопку «Войти».
Если создать новый кабинет вместо старого, то все баллы, бонусы и прочие плюшки, накопленные ранее, увы, пропадут.
Фейсбук: Создать аккаунт и Вход
Знакомый пенсионер активно осваивал Фейсбук. Он часто присылал повторные приглашения в друзья, потому что постоянно создавал новые аккаунты. На старый аккаунт он не мог попасть по разным причинам. Новая регистрация ему была нужна, потому что он никогда не записывал старый логин и пароль, не сохранял, не запоминал. Он уверен, что это для него лишняя, утомительная процедура.
При этом знакомый удивлялся, почему у него так мало друзей и почему в новом аккаунте все друзья пропадают. А как Фейсбук догадается, что тот или иной человек создал сразу несколько разных аккаунтов? Кстати, если Фейсбук догадается, то может предупредить о неправильных действиях, так как у одному человеку желательно иметь один единственный аккаунт.
Кнопка «Создать аккаунт» (цифра 1 на рисунке 5) предназначена для создания новой личной странички, где нет друзей, и все «с чистого листа». А кнопка «Войти» предназначена для входа на личную страничку, ранее уже зарегистрированную, и возможно, там уже есть друзья.
ВКонтакте: Регистрация и Войти
Чтобы создать новую страничку ВКонтакте, следует ввести имя, фамилию, указать дату рождения и нажать на зеленую кнопку «Продолжить регистрацию».
Для входа на свою страничку, ранее уже зарегистрированную, следует ввести телефон или email, пароль и нажать «Войти».
Тонкости авторизации: обзор технологии OAuth 2.0
Информационная система Dodo IS состоит из 44 различных сервисов, таких как Трекер, Кассы ресторана или Базы знаний и многих других. Чтобы не отвлекаться на несколько аккаунтов, 3 года назад мы написали сервис Auth для реализации сквозной аутентификации, а сейчас пишем уже вторую версию, в основе которого лежит стандарт авторизации OAuth 2.0. Этот стандарт довольно сложный, но если у вас сложная архитектура с множеством сервисов, то OAuth 2.0 вам пригодится при разработке своего сервиса аутентификации. В этой статье я постарался рассказать о стандарте максимально просто и понятно, чтобы вы сэкономили время на его изучение.
Задача Auth
Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад — в начале «эпохи распила монолита». Эту проблему решили новым сервисом, который назвали – Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных.
У сервиса Auth есть три основные задачи:
Проблемы
Первая версия Auth — часть монолита. Он использует свой собственный протокол общения с сервисами. Такая «схема» была необходима в тот момент, но за несколько лет работы проявились проблемы.
Auth — часть монолита. Следовательно, сервис привязан к релизному циклу, что лишает возможности независимой разработки и деплоя. Кроме того, придется разворачивать весь монолит, если захотелось развернуть Auth, например, при масштабировании сервиса.
Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth «приляжет» по какой-то причине.
Auth зависит от Redis. Притом достаточно сильно — неисправность работы Redis’а приведёт к падению Auth’а. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.
Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.
Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё. Но у нас нет выдачи прав на конкретные компоненты системы. Приходится выдавать полный доступ к сервису, чтобы сотрудники могли получить доступ к составлению графиков или настройкам какого-либо компонента учёта.
Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0.
Примечание. Утрированно, статья — это пересказ RFC, который приходилось перечитывать несколько раз, чтобы понять, что происходит вокруг. Здесь я постарался уйти от этой сложности и рассказать всё максимально просто, структурировано, кратко и без описания сложных вещей, например, какие символы может содержать в себе ответ сервиса. В отличии от RFC, прочитав это один раз, можно во всём разобраться. Надеюсь, статья будет полезна и сэкономит время при выборе решения для реализации сервиса аутентификации, а может, кого-то заставит задуматься о его необходимости.
Что такое ОAuth2.0?
Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth2.0.
Стандарт был принят в 2012 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.
Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем.
OAuth 2.0 — это фреймворк авторизации.
Он описывает, как должно реализовываться взаимодействие между сервисами для обеспечения безопасной авторизации. Многие нюансы описаны достаточно подробно, например, flow взаимодействия узлов между собой, но некоторые отдаются на откуп конкретной реализации.
В OAuth 2.0 определены четыре роли:
Важно: клиент должен быть заранее зарегистрирован в сервисе. Как это сделать?
Регистрация клиента
Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от фантазии конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.
Redirection URI — адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.
Client type — тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации — токен. Поэтому существует всего 2 типа клиентов:
Токены
Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).
У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю.
Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением. Но это не безопасно. Если access token был скомпрометирован, его можно обнулить, а сервис получит новый Access token с помощью refresh token. В случае, если refresh token нет, то потребуется проходить процесс авторизации заново.
За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.
Права доступа
Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.
На этапе регистрации клиента, в настройках сервиса авторизации клиенту выдаётся стандартный scope по умолчанию. Но клиент может запросить у сервера авторизации scope, отличный от стандартного. В зависимости от политик на сервере авторизации и выбора владельца ресурса, итоговый набор scope может выглядеть совсем иначе. В дальнейшем, после авторизации клиента, владелец ресурсов может отобрать часть прав без повторной авторизации сервиса, но, чтобы выдать дополнительные разрешения, потребуется повторная авторизация клиента.
Абстрактный OAuth 2.0. Flow c применением Access token
Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.
Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.
Абстрактный OAuth 2.0. Flow c применением Refresh token
Первый и второй шаги опущены из данной схемы — они ничем не отличаются от схемы абстрактного flow выше.
Что такое grant?
Grant — это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для получения access token.
Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется «Consent Screen».
В момент, когда нажимаем «ОК», в базу данных попадает тот самый grant: записываются данные о том, что такой-то пользователь дал такие-то доступы такому-то сервису. Клиент получает какой-то идентификатор успешной аутентификации, например строку, которая ассоциируется с данными в базе данных.
Существует 4 + 1 способа получения grant — grant type:
Client credentials grant flow
Имеет самый простой flow, напоминающий обычную авторизацию на любом сервисе. Она выполняется с помощью учётных данных клиента, которые представляют собой client id и client secret — аналог логина и пароля для пользователя. Так как для аутентификации требуется client secret, который должен соответствующе храниться, данный flow могут использовать только confedential клиенты.
Схема проста: клиент аутентифицируется на сервере авторизации передавая client id и client secret. В ответ получает access token, с которым уже может получить доступ к нужному сервису.
Этот flow требуется, когда клиент пытается получить доступ к своим ресурсам или ресурсам, заранее согласованным с сервером авторизации. Например, сервису А нужно время от времени ходить в сервис Б и актуализировать там данные о количестве пиццерий в сети.
Resource owner password credentials flow
По текущим рекомендациям безопасности описанных в данном RFC, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.
Resource owner передаёт свой логин и пароль клиенту, например, через формы на клиенте. Клиент, в свою очередь, с помощью него получает access token (и, опционально, refresh token).
Здесь есть проблема. Resource owner просто берёт и отдаёт в открытом виде свой логин и пароль клиенту, что не безопасно. Изначально он был сделан только для клиентов, которым вы доверяете или тех, что являются частью операционной системы. Позже он был разрешён только для миграции с аутентификации по логину и паролю на OAuth 2.0. Текущие рекомендации по безопасности запрещают его использование.
Authorization code
Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов.
В данном flow взаимодействие client с resource owner проходит через user-agent (браузер). К user-agent есть одно требование: он должен уметь работать с HTTP-редиректами. Без этого resource owner не сможет попасть к серверу авторизации и вернуться обратно с grant.
Данный flow сложнее, чем предыдущие, поэтому будем разбирать по шагам. Для начала представим, что мы — resource owner и перешли на страницу сервиса онлайн-обучения, который хочет сохранять результаты обучения к нам в облако. Ему требуется получить доступ к нашему ресурсу, например, определённой директории в облаке. Мы нажимаем на «Авторизоваться» и начинается путешествие по Authorization code grant flow:
Следующий flow построен на основе этого.
Implicit grant
Это оптимизация Authorization code grant flow для public-клиентов, которые умеют работать с redirection URI. Например, для браузерных приложений на JavaScript, или мобильных приложений. Требование к user-agent, с помощью которого взаимодействуют клиент и resource owner, сохраняется: он должен уметь работать с HTTP-редиректами.
Между authorization code и implicit есть основное отличие: вместо получения authorization code и access token по нему, мы сразу получаем access token после успешной авторизации resource owner. Кроме того, здесь не используется client secret из соображений безопасности — приложение можно дизассемблировать и получить его. Подлинность проверяется только по redirection URI.
Многие шаги из данной схемы похожи на шаги из authorization code, но предлагаю их разобрать также подробно. Представим, что некое браузерное приложение хочет сохранять свои настройки в нашем Git-репозитории. Мы нажимаете «Войти в GitHub» и на этом этапе начинается работа Implicit flow:
Device authorization (RFC 8628)
С 2012 до 2019 появилось много умных устройств, на которых неудобно авторизоваться. Например, неудобно вводить сложный логин и пароль на телевизоре каждый раз при открытии ресурса. На некоторых устройствах это невозможно, например на серверных ОС без графического интерфейса. В августе 2019 этот flow появился как раз для таких сценариев.
Есть, как минимум, 3 требования к устройствам, чтобы работа с помощью Device authoraztion grant flow была возможна:
Возможно, схема кажется сложной из-за обилия стрелок. Разберём её также пошагово, как и разбирали сложные flow до него.
Представим, что мы пытаемся авторизоваться на web-сервисе с помощью телевизора. Мы видим кнопку «Авторизоваться как устройство» и нажимаем. В этот момент начинается наш Device flow:
Вместо вывода
В этой статье я опустил много подробностей, чтобы максимально просто и доступно рассказать о самом важном. Например, типы запросов, как и в каком виде передавать параметры, какие символы допустимы в качестве значений для того.
Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.
Если статья была полезна и захотите подробностей — пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.