Как стать автором
Обновить

Комментарии 9

Простите, о чём вообще речь? Почему для статьи выбраны именно эти способы аутентификации? Почему исключены другие?
Это наиболее типичные способы аутентификации (в мобильных приложениях), с которыми автору приходилось сталкиваться (не считая технологии Sony). Они приведены по принципу нарастания сложности. Если чего-то важного, по вашему мнению, не хватает, прошу сообщить — буду рад добавить в обзор.
с которыми автору приходилось сталкиваться
Может быть именно с этого и стоило начать обзор? И может быть стоило немного рассказать об архитектуре протоколов, как их отлаживать, как настаивать? В статье не очень понятно в каком случае какому протоколу отдавать предпочтение. Тот же — SSO — это не только oAuth. Kerberos это же тоже SSO, только в рамках домена, чтобы пользователю не приходилось вводить пароль при подключении к каждому ресурсу. Можно ведь сделать, например, двухфакторную аутентификацию на основе kerberos. Можно сделать n-уровневую аутентификацию в принципе. Ведь читателю в принципе не понятно, а что такое уровень вообще?
Да, это интересный аспект, какой из протоколов выбрать. Спасибо!
В принципе, можно было бы составить сводную табличку с пересечением критериев/требований и подходящих протоколов — но тут, как мне видится, слишком много факторов.
Слишком много факторов?
Я бы анимированные гифки вставил, например, а то название способов аутентификации — это просто набор символов. И если читатель их ни разу не видел, то для него они так и останутся названиями.
автор молодец, приятно читать инфу. Особую благодарность выражу за проведенные аналогии, местами комичные. Усваивается определенно легче
Результатом решения проблемы стали аутентификация oAuth и принцип SSO…

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

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

А в следующем абзаце поясняете, что речь про пароли. Но в случае с OAuth вам не надо хранить пароли на устройстве.

Многофакторная аутентификация бывает разная. То, что вы называете пин-кодом на самом деле является одноразовым паролем.

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

Спасибо за развёрнутый комментарий. Что касается цитаты, посмотрите на выше приведённую ссылку — там есть не только описание патентуемого метода, но и картинки, из которых, как мне кажется, всё хорошо видно.
Статья называется «Аутентификация в мобильных приложениях», а приведён обзор методов аутентификации в принципе.
в контексте названия интересно было бы более подробно почитать, например, про best practices построения систем авторизации в мобильных приложениях: с OAuth, без неё и тд
Зарегистрируйтесь на Хабре, чтобы оставить комментарий