Сервер авторизации Okta, использующий проблемы с пользовательским доменом

#node.js #authentication #okta #okta-api

#node.js #аутентификация #okta #okta-api

Вопрос:

Моя компания использует Okta Developer Edition, и у нас есть существующая интеграция, которая использует сервер авторизации по умолчанию. Он настроен следующим образом (orgid отредактирован):

 Name: default
Audience: api://default
Issuer URI: https://dev-XXXXXXXXX.oktapreview.com/oauth2/default
 

Мы хотим использовать пользовательский домен для наших потоков аутентификации, поэтому мы прошли пошаговое руководство по пользовательскому домену, добавили записи DNS, все проверили и в конечном итоге смогли настроить новый пользовательский домен.

Затем мы создали второй сервер авторизации без изменения сервера по умолчанию и настроили пользовательский домен на новом сервере из выпадающего списка, аналогично:

 Name: Custom Domain
Audience: https://account.mycompany.com
Issuer URI: https://dev-XXXXXXXXX.oktapreview.com/oauth2/default
 

ОДНАКО после сохранения этого нового сервера аутентификации он нарушил наш существующий поток аутентификации в производстве!

Кто-нибудь еще сталкивался с этим раньше или знает, как решить? Нам пришлось удалить новый сервер авторизации и пользовательский домен и дождаться распространения DNS, чтобы проблема окончательно разрешилась, поэтому теперь мы боимся снова создавать пользовательский домен. Пожалуйста, помогите.


Обновить

Хорошо, мы поняли одну вещь — при первом создании нового сервера авторизации мы ошибочно установили для аудитории то же значение, что и для сервера авторизации по умолчанию, т. Е.:

 Audience: api://default
 

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

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

1. Где он сломался? Если это было на этапе проверки JWT, может быть несоответствие эмитента — ваш код выполняет вызовы /authorize и /token для домена Okta, а для эмитента сервера авторизации установлен новый пользовательский URL-адрес или наоборот.