Первоначальный запрос API для получения токена сеанса (обратите внимание, не готовить ie) - это внутренний вызов приложения из API-интерфейса OneLogin, поэтому он не отображается в браузере пользователя, но вы можете видеть, что этот вызов API возвращает маркер JWT с 2-минутным таймаутом в приложение клиента. Вы можете перейти к https://jwt.io/ и нажать Отладчик для подтверждения. С правой стороны будет область истечения срока действия, и вы можете навести на нее курсор, чтобы увидеть срок действия. С ним всегда связан 2-минутный тайм-аут.
В этом случае ваше приложение должно указать браузеру пользователя отправлять токен с полезной нагрузкой HTTP в OneLogin по адресу "/ session_via_api_token", чтобы обеспечить сеанс готовить ie в браузер. Вы можете использовать расширение SAML Tracer в своем браузере для захвата трассировки SAML для проверки, просмотрев вкладку «HTTP» строки POST для «session_via_api_token». Примечание. Установлено 3 файла cookie, из которых 2 являются постоянными и сразу же истекают, поэтому они не служат цели. Так что не подчеркивайте тот факт, что срок действия этих двух файлов cookie истек, так как они не актуальны. Ключевым поваром ie является «subsession_onelogin.com», который является сеансовым поваром ie и поэтому не имеет времени истечения. Он используется для отслеживания времени ожидания сеанса.
Если пользователь затем пытается получить доступ к ресурсу OneLogin, то он включает в себя новый "subsession_onelogin.com" cook ie и поэтому считается аутентифицированным. Затем OneLogin выпускает обновленную версию этого повара ie, которую вы можете увидеть в SAML Trace в строке GET для области "sub_session.onelogin.com" Set-Cook ie.
Появляется то, что метод CORS работает для этого API, немного отличается от метода публикации формы, и команда API была проинформирована об этом, поскольку статья Dev, вероятно, будет обновлена, чтобы утверждать, что предлагается метод публикации формы.
Кроме того, в моем тестировании оказалось, что некоторые браузеры реагируют по-разному, поэтому тестирование других браузеров, безусловно, пролило бы больше света. Это спецификация браузера c, и поэтому не будет связана с вызовами API. С помощью запроса «Создать сеанс» в Safari, когда включена настройка по умолчанию «Запретить межсайтовую готовку ie Отслеживание», я заметил, что файлы cookie возвращаются ожидаемым образом, но браузер отказывается их принимать. В консоли браузера нет предупреждений или ошибок. Неизвестно, почему Safari делает это и не может найти какую-либо документацию по этому поводу, так что это проблема, определяемая браузером c, вне нашего контроля.
Браузеры усложняют ситуацию, поэтому наша команда API, вероятно, обновит нашу лучшую практику Руководящие принципы в ближайшие месяцы, чтобы сказать, чтобы использовать форму после перенаправления, а не CORS. Метод post form должен работать для всех браузеров, так как они обрабатывают его иначе, чем метод CORS.
Первая ссылка в документации API - https://developers.onelogin.com/api-docs/1/login-page/create-session-via-token и вторая ссылка для ее использования https://developers.onelogin.com/api-docs/1/login-page/create-session-login-token. Затем вы можете использовать https://jwt.io/ и нажать Отладчик для проверки. Это работает должным образом с 2-минутным истечением, которое является правильным. Ключевой повар ie - это «subsession_onelogin.com», который является поваром сеанса ie и поэтому не имеет срока действия, так как он используется для отслеживания времени ожидания сеанса.
В моих тестах я проверял, что определенно есть 2-минутное время жизни, и именно так оно и должно работать. В моем примере тестов показано, что ответ API требует истечения срока действия в 16:19:04, что соответствует декодеру jwt.io (этот сайт полезен для этого). Вторая часть теста вернула параметр DATE заголовков, который показывает, что время выпуска было 16:17:04; т.е. за 2 минуты до истечения срока. Это правильно.
Я полагаю, что проблема, с которой вы столкнулись, вызвана тем, как ваше приложение направляет браузер пользователя на вызов "/ session_via_api_token" - если приложение использует CORS, то, очевидно, вам нужно будет включить соответствующие заголовок. Однако, похоже, что даже с этим заголовком некоторые браузеры не будут отправлять запрос CORS (предположительно из-за настроек безопасности браузера), и поэтому сеанс никогда не будет установлен. По крайней мере, это то, что я вижу при использовании примера пользовательской страницы входа в систему при тестировании. Примечание. Первый вызов - это вызов API REST (т. Е. Для чего нужен Postman), но второй запрос - это обычный запрос браузера.