Работа с истекшим токеном доступа в неявном гранте OAuth2

В спецификации OAuth2 указано, что сервер авторизации не должен выдавать токен обновления при использовании неявного разрешения. В нашем случае мы защищаем RESTful API с OAuth2 и используем приложение Single Page Javascript как клиент для этого API. Поскольку было бы очень сложно перенаправить на сервер авторизации после того, как токен доступа истёк, мы ищем лучший способ получить новый действительный токен. Я мог бы думать о двух разных подходах и удивляться, какой из них может быть лучше:

Используйте скрытый iframe для повторной проверки допустимого токена доступа. Для этого необходимо включить параметр "prompt = none", который сообщает провайдеру OAuth ни о вызове проверки подлинности, ни в отображении страницы авторизации. Если пользователь аутентифицирован и авторизовал приложение, сервер отправит токен доступа в параметры URL-адресов. Если одно из предыдущих условий не выполнено, оно будет перенаправлено с ошибкой, например # error = authentication %20lost. При таком поведении мы можем использовать краткосрочные токены доступа также с неявным потоком.
Мы могли бы использовать дополнительную область (например, офлайн), которая сообщает серверу передать токен обновления. Даже если исходная спецификация говорит о том, что неявный поток не выдаёт токены обновления (это верно, если клиент использует OAuth только для первой авторизации), вы можете свободно определять свои собственные области для своего конкретного приложения. Вы должны учитывать только эту область видимости от известных клиентов.

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

Итак, какой подход должен быть предпочтительным?

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

Ответ 1

Я пытаюсь достичь той же самой вещи в данный момент.

Я действительно реализовал подход скрытый iframe, а затем понял, что вы должны быть очень осторожны с iframes. Любой вредоносный веб-сайт может содержать ваш iframe и легко получить токен доступа, если вы не укажете X-Frame-Options.

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

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

Edit

Я понял, что даже с X-Frame-Options большинство браузеров не могут предотвратить перенаправление, потому что этот заголовок прикреплен к телу ответа, и перенаправленный URL-адрес будет открыт, поэтому открываются токены доступа.

Обновление Похоже, хэш-фрагмент защищен браузером при доступе с родительской страницы в другом домене. Поэтому я предполагаю, что #access_token безопасен. Виноват. Так же, как страница обратного вызова напоминания должна хранить маркер доступа самостоятельно, а не (мое первоначальное намерение) делегировать его родительской странице, например window.parent.storeAccessToken(hash);, что, очевидно, является немой задачей.

Ответ 2

На веб-сайте OAuth0:

Если вам необходимо аутентифицировать своих пользователей без страницы входа (например, когда пользователь уже зарегистрировался через сценарий SSO) или получить новый access_token (таким образом, имитировать обновление истекшего токена), вы можете использовать Silent Authentication.

Что касается Silent Authentication:

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

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