В чем разница между использованием токена обновления и тихой аутентификацией для SPA?
Насколько я понимаю, вы не должны выпускать токен обновления для SPA. Но есть варианты получения нового токена доступа, например, тихая аутентификация.
Чтобы упростить задачу, вы предоставляете токен обновления серверу авторизации (AS) и получаете новый токен доступа. При тихой аутентификации вы передаете текущий токен доступа какой-либо конечной точке в AS, и если он действителен, вы получаете новый токен доступа.
Пожалуйста, поправьте меня, потому что я не понимаю, почему тихая аутентификация является более безопасным подходом.
Ответы 1
With silent authentication you pass current access token to some endpoint on the AS and if it is valid you get a new access token.
Это не так.
Поток с тихой аутентификацией выглядит так:
Сервер аутентификации (AS) и клиент (SPA)
- SPA перенаправляет пользователя для входа в систему с AS.
- AS выполняет вход пользователя в систему и перенаправляет обратно в SPA с токеном доступа, который можно использовать для доступа к API.
- SPA вызывает API, пока не получит 401. (или использует какой-либо другой механизм для определения времени для получения нового токена доступа)
- SPA выполняет тихий GET в AS
Конечная точка
authorizeпытается получить новый токен доступа. Это не необходимо предоставить старый просроченный токен доступа. - У пользователя
IF AND ONLYвсе еще есть действительный сеанс с AS (вероятно, какой-то файл cookie аутентификации), тогда AS будет ответить действительным токеном доступа (если AS считает, что запрос действительный).
Хороший статья, объясняющий тихую аутентификацию
Почему предпочтительнее использовать cookie аутентификации и токен обновления - этот вопрос поясняет это.
Разница здесь по сравнению с неявным потоком заключается в том, что при тихой аутентификации вы должны использовать поток кода авторизации. При менее удобном для пользователя подходе, если вам нужен новый токен доступа, вы будете перенаправлены в AS, а затем сразу же вернетесь с ответом на предоставление кода авторизации. Когда ваш клиент получит это, он произведет обмен токена. Теперь, чтобы решить эту проблему UX, вам нужно проделать некоторые уловки и нестандартные вещи, например, загрузить конечную точку аутентификации сервера AS в iframe и использовать API обмена сообщениями HTML 5 для отправки кода авторизации клиенту.
@ alex-buyny, если у пользователя все еще есть действующий сеанс с AS, как AS генерирует новый токен доступа, использует ли он refresh_token, хранящийся внутри сеанса AS?
@ alex-buny Да, если вы не используете токен обновления, вам нужно использовать файлы cookie. А про аутентификацию нет ничего «молчаливого». На определенном этапе процесса пользователи должны ввести свои учетные данные. Просто, если срок их входа на основе файлов cookie еще не истек, они могут получить новый токен доступа в любое время без нового взаимодействия. Как указано в ссылке, вы действительно говорите о Неявный поток OIDC. Время жизни сеанса контролируется сервером входа в систему, который предоставил вам файлы cookie.