Аутентификация мобильных приложений
Исторически сложилось так, что аутентификация в мобильных приложениях не сильно отличается от аутентификации в веб приложениях. Однако для мобильных приложений есть ключевые особенности:
- Интерфейс пользователя в мобильном приложении основывается не на стороне сервера, поэтому любые изменения в интерфейсе (в т.ч. новые методы аутентификации) требуют разработки новой версии приложения. Это требует времени и отвлекает от реальной работы над приложением.
- Для веб приложений уже много лет успешно применяется SAML для того, чтобы переложить задачу аутентификации на другой сервер. Так веб приложение может фокусироваться на основной задаче. Интеграция подобного подхода (редиректы, POST запросы) для мобильных приложении требует значительного времени и трудоемкой работы.
- Еще одно отличие в том, что при работе с мобильным приложением пользователь не готов аутентифицироваться каждый раз при запуске приложения. Поскольку он работает со своего устройства, он ожидает, что аутентифицировавшись единожды он остается залогиненым. Возможно, что и не с полным доступом. Предложение аутентификации может появиться для некоторых операций, например, перевод денег.
Классическое мобильное приложение
Ключевые особенности разработки мобильного приложения такие:
- Возможность использовать тех же пользователей и паролей, как и для веб приложений, чтобы пользователи не учили новые пароли или новые методы аутентификации, то есть аутентификация в мобильных приложениях должна быть встроена в текущую аутентификацию
- Долговременные сессии с ограниченным доступом. Это возможно с OAuth2
- Перенос аутентификации от приложения, что позволяет избежать изменений в приложениях при добавлении новых методов аутентификации
- Пароли приложений не хранятся локально и не передаются в заголовке HTTP basic
- Возможность закрыть доступ к определенным приложениям не влияя на другие приложения и не заставляя пользователей менять пароли
- Добавление многофакторной аутентификации не должно приводить к переработке всех аутентификационных процессов приложения
- Необходимость предоставить мобильному приложению делегированный доступ, но не полный доступ к аккаунту пользователя, то есть разрешить ограниченный доступ
- Нежелательно распространять учетные данные и хранить их на мобильных устройствах
Hybrid Access Gateway (HAG) позволяет решить эти задачи разными способами
Расположение API, отвечающего за работу мобильного приложения позади HAG – режим прокси.
1. Пользователь направляется на Access Gateway, который будет управлять аутентификацией и контролем доступа. 2. Пользователь аутентифицируется и запрашивает права на доступ к API. 3. Пользователю возвращается токен. 4. Приложение использует токен для доступа к API
Многие задачи переносятся на Access Gateway
Если же использование прокси по каким-то причинам невозможно или нежелательно, то можно использовать так называемый самоанализ токена (token introspection).
Разделение API и Access Gateway (token introspection)
Наконец, можно делать то же самое для всего набора приложений и API, получив тем самым единую точку аудита.
Управление аутентификацией и авторизацией для нескольких приложений при помощи Access Gateway
Сервер аутентификации