Я создаю многопользовательское приложение ASP.NET Core, в котором пользователи могут принадлежать одному или нескольким клиентам. Когда пользователь пытается аутентифицироваться, я хотел бы сгенерировать JWT с userId и tenantId в качестве утверждений, чтобы API могли использовать эти значения вместо того, чтобы их приходилось каждый раз передавать через маршрут или объект тела. В настоящее время, если пользователь связан только с одним клиентом, это просто, я просто генерирую утверждение JWT tenantId с единственным, с которым они связаны. Но если пользователь связан более чем с одним, то какой будет моя стратегия?
Для ясности с точки зрения пользовательского интерфейса представьте стандартную форму входа по электронной почте / паролю. Если связано с одним арендатором, вы попадете на целевую страницу этого арендатора. Если связан с несколькими арендаторами, перейдите к экрану выбора арендатора.
В настоящее время я думаю, что у меня будет два «типа» токенов JWT: UserToken и TenantUserToken. UserToken, по сути, будет просто userId успешно аутентифицированного адреса электронной почты / пароля, который затем может быть использован для доступа к нескольким конечным точкам, например, для просмотра того, с какими лигами связан userId UserToken, или для выполнения общих действий по управлению пользователями, которые не связаны с каким-либо конкретным жилец. TenantUserToken будет полностью заполненным токеном с tenantId и будет основным средством проверки подлинности для большинства конечных точек действия клиента. Ниже приводится обобщение того, о чем я думаю:
AppToken AuthenticateUser(string email, string password, int? tenantId)
{
var user = ValidateUser(email, password);
if (user == null){
//return error "email and/or password incorrect"
}
if (tenantId != null){
bool valid = ValidateTenantUser(user, tenantId);
if (valid){
//return error "user does not have access to tenant"
}else{
//return TenantUserToken
}
}
if (user.associatedTenants.count != 1){
//return UserToken
}else{
//return TenantUserToken
}
}
public class AppToken{
public string Token;
public TokenType TokenType; //enum of TenantUserToken or UserToken
}
Я вполне мог бы слишком обдумать это, но я крутил это достаточно долго, я думал, что протяну руку и посмотрю, есть ли у кого-нибудь еще мысль?
@juunas Я тоже думал об этом. Сохраняя доступных арендаторов на токене, я бы также сэкономил поездку в БД, чтобы получить список арендаторов, но, как вы упомянули, в любое время, когда я хотел бы назначить активного арендатора, я бы генерировал новый токен.
Используйте cookie для текущего арендатора.
Привет, Бен, какое решение ты получил? Мы сталкиваемся с той же проблемой и думаем о выпуске нового токена, когда пользователь переходит на другого клиента. Спасибо!
@lucbas В итоге я построил свое приложение в контексте одного «текущего выбранного клиента», а затем выпустил новый токен, когда пользователь меняет клиента, и я был доволен результатом.





Вы можете сохранить все идентификаторы арендатора в токене (если они подходят) и сохранить дополнительное утверждение, которое является активным идентификатором арендатора. Тогда переключение арендатора, конечно, требует генерации нового токена. Просто идея :)