Возможно, вопрос более всеобъемлющий, чем заголовок.Есть много постов об аутентификации, токенах, JWT, Azure AD и т. Д., Но все эти посты, кажется, рассказывают другую историю, которая делает базовую концепцию, по крайней мере для меня, немного неясной.Я постараюсь объяснить мои вопросы, используя мой случай.
Я создал приложение Frontend с React в визуальном коде и приложение Backend в Visual Studio .Net Core 2 (веб-API).Приложение размещается в Azure, и мы хотели бы выполнить проверку подлинности с помощью Azure AD.
Интерфейс использует Adal-React (https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-libraries) и Axios (https://github.com/axios/axios).
). С помощью обучающих программ я настроил конфигурацию в интерфейсе и в API (бэкэнд),используя именно TenantID и ClientID, которые перечислены в среде Azure.
Хотя я настроил его и он работает, способ его работы мне более или менее неясен.
Я попытаюсь объяснить текущий рабочий процесс в моих приложениях, как он есть, и перечислил мои текущие вопросы ниже:
1 - пользователь переходит к веб-приложению, адаль проверяет, если пользовательаутентифицируется, и если это не тот человек, который перенаправляется в нашу среду входа в Azure, это настраивается в конфигурации adal (внешний интерфейс) следующим образом:
const adalConfig = {
tenant: 'vhsprod.onmicrosoft.com',
clientId: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx',
endpoints: {
api: 'https://xxxxx.onmicrosoft.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx (client id)',
},
postLogoutRedirectUri: window.location.origin,
redirectUri: 'http://localhost:3000/user-form',
cacheLocation: 'sessionStorage'
};
export const authContext = new AuthenticationContext(adalConfig);
export const getToken = () => {
return authContext.getCachedToken(authContext.config.clientId);
};
2 - пользовательНужно войти в систему и проверяется, существует ли пользователь в среде Azure AD, если это так, то пользователь перенаправляется обратно на веб-интерфейс, и мы получаем себе токен .
3 - Пользователь открывает форму / страницу во внешнем интерфейсе, для которой требуются данные из внутреннего интерфейса, выполняется вызов API с только что полученным токеном.Вызов выполняется с помощью Axios во внешнем интерфейсе, Axios также настроен:
export const axiosCallToMyAPI = axios.create({
baseURL: 'http://localhost:52860/api/',
timeout: 5000,
headers: {'Authorization': 'Bearer ' + initialToken}
});
Исходный токен поступает от Adal, токен, который мы только что получили:
let initialToken = sessionStorage.getItem('adal.idtoken')
4 - выполняется вызов API, и здесь мы также настроили конфигурацию (appsettings.json) для использования Azure AD:
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantDomain": "xxxx.onmicrosoft.com",
"TenantId": "xxxx.onmicrosoft.com",
"ClientId": "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
}
5 - В классе запуска API токен проверяется:
services
.AddAuthentication(sharedOptions =>
{
sharedOptions.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
sharedOptions.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
sharedOptions.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
options.Audience = this.Configuration["AzureAd:ClientId"];
options.Authority = $"{this.Configuration["AzureAd:Instance"]}{this.Configuration["AzureAd:TenantId"]}";
options.Events = new JwtBearerEvents()
{
OnTokenValidated = context =>
{
return Task.CompletedTask;
}
};
});
Остались вопросы и сделанные мной предположения (чтение нескольких постов):
- С токеном Azure, который получает интерфейс, выполняется вызов API, как API узнает, что этот токен «действителен»?Я знаю, что класс запуска API использует событие
OnTokenValidated, но в чем заключается магия этого ?Это просто проверка настроенного идентификатора клиента / клиента в appsettings с полученным токеном? - В нескольких сообщениях они используют / упоминают SecretKey / Signing Key, в моем примере, однако, я не реализовал SecretKey, но он все еще работает.Нужно ли реализовывать секретный / подписывающий ключ в моем API (бэкэнд)?Это необходимо?
- Я также прочитал о неявном потоке, OpenID connect и некоторых других терминах.Когда вы используете аутентификацию Azure AD, как в моем примере, и делаете это таким образом, я автоматически выполняю
implicit flow (frontend -> backend) и аутентификацию с openid connect?Другими словами, когда вы используете аутентификацию Azure, вы автоматически выполняете эти / передовые практики или все-таки должны их реализовать? - У токена есть определенные претензии /.определены области, которые предоставляются Azure (где вы также можете установить эти утверждения, такие как электронная почта и роли), однако при использовании AspNet (Identity) вы также можете добавить свои собственные утверждения в текущий токен / сеанс, например, когда я добавляю ролевой запросот незаметности до моего жетона.Чем эти претензии отличаются от первоначальной претензии (все еще предъявитель / JWT?) И является ли это хорошей практикой?
Может ли кто-нибудь подтвердить / объяснить эти вопросы?
Приношу свои извинения, если история немного общая, но в настоящий момент наш уровень пробных ошибок слишком высок, и я просто пытаюсь прояснить ситуацию.