Я только что закончил применять этот пример быстрого старта из документации IdentityServer4. В настоящее время у меня есть 3 приложения: одно для входа в систему (я назову его «страницей входа»), одно - конечная точка webapi, а второе - javascript SPA (одностраничное приложение).
Если одна из конечных точек webapi требует аутентификации пользователя, она сообщает об этом приложению SPA. Затем приложение SPA перенаправляет меня на страницу входа, которую я недавно развернул в Интернете.
Теперь эта конфигурация:
// JavaScript Client
new Client
{
ClientId = "js",
ClientName = "JavaScript Client",
AllowedGrantTypes = GrantTypes.Implicit,
AllowAccessTokensViaBrowser = true,
RedirectUris = {
"http://localhost:5003/auth-callback",
"http://localhost:5003/assets/silent-refresh.html"
},
PostLogoutRedirectUris = { "http://localhost:5003/" },
AllowedCorsOrigins = { "http://localhost:5003" },
AllowedScopes =
{
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
"api1"
}
}
работает хорошо, пока страница входа в систему работает на localhost.
Теперь я развернул страницу входа в Интернет. Это означает, что после успешного входа в систему он попытается перенаправить пользователя на:
который не будет работать, поскольку он локальный, недоступный по URL-адресу в Интернете.
Теперь, имея в виду, что мне нужно локально тестировать приложения SPA: как я могу настроить IdentityServer4, чтобы я мог тестировать свои приложения локально, но с использованием поставщика удостоверений, размещенного в Интернете?
Как? Изменение RedirectUris
, например, на "/ auth-callback" вместо "локальный: 5003 / auth-callback" вызывает ошибку "Invalid redirect_uri"
Данный пример из документации - это всего лишь пример. В реальном приложении вы хотите добавлять новых клиентов через пользовательский интерфейс, а не в качестве заполнения приложения, поскольку хранить учетные данные в исполняемом файле - глупая идея. Вам необходимо добавить НОВЫЙ КЛИЕНТ для вашего производственного приложения и использовать его идентификатор клиента при аутентификации.
Причиной этого является безопасность, поэтому злоумышленник не может просто использовать ваш идентификатор клиента (и секрет) и аутентифицировать пользователей в своей системе, потому что он будет перенаправлен обратно на реальный веб-сайт, настроенный в idsrv4, поэтому злоумышленник не сможет фишинг для токенов, позволяя пользователю пройти аутентификацию и вернуться на свой сервер
@Tseng альтернативой использованию пользовательского интерфейса и динамическому добавлению клиентов может сохранять их список в appsettings.json (если список будет более или менее статичным).
Есть ли примеры того, как это будет реализовано в реальной жизни? Потому что я немного запутался
Вы пробовали использовать URL-адрес родственник?