Использование Id_token из Azure с использованием UseWindowsAzureActiveDirectoryBearerAuthentication

Question

Требуется помощь от кого-либо.

У меня есть клиентское приложение SPA, которое общается с WebApi (.Net 4.52).Оба были разработаны моей компанией.Он отлично работал с токенами, которые генерировал сам WebAPI (основываясь на превосходных статьях из bitoftech )

Теперь мы хотим разрешить аутентификацию с помощью Azure - точнее, моего клиентасобственный лазурный арендатор (который я не могу контролировать напрямую).Чтобы сделать это на стороне клиента, мы используем adal.js, чтобы выполнить вход пользователя в систему и использовать UseWindowsAzureActiveDirectoryBearerAuthentication на стороне сервера, чтобы проверить токены Azure.

OauthЗапуск выглядит следующим образом:

public static void RunAcademyOAuthStartup(IAppBuilder app)
{            
        if (ConfigurationManager.AppSettings["ida:Enabled"] == "1")
        {
            app.UseWindowsAzureActiveDirectoryBearerAuthentication(
                new WindowsAzureActiveDirectoryBearerAuthenticationOptions
                {
                    TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
                    {
                        ValidAudience = ConfigurationManager.AppSettings["ida:Audience"],
                        AuthenticationType = "ExternalAzureSSO"
                    },
                    Tenant = ConfigurationManager.AppSettings["ida:Tenant"]

                }
            );
        }


        var apiAccessTokenLifeTimeSeconds = 0;
        if (!int.TryParse(ConfigurationManager.AppSettings["ApiAccessTokenLifetimeSeconds"], out apiAccessTokenLifeTimeSeconds))
        {
            apiAccessTokenLifeTimeSeconds = 1800; //set default to 30 minutes
        }

        var oAuthServerOptions = new OAuthAuthorizationServerOptions()
        {
            AllowInsecureHttp = true,
            TokenEndpointPath = new PathString("/api/user/authenticate"),
            AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(apiAccessTokenLifeTimeSeconds),
            Provider = new SimpleAuthorizationServerProvider(),
            RefreshTokenProvider = new SimpleRefreshTokenProvider(),
            AuthenticationType = "LocalApplication"
        };

        OAuthBearerOptions = new OAuthBearerAuthenticationOptions();

        // Token Generation - setup the token authorization server
        app.UseOAuthAuthorizationServer(oAuthServerOptions);
        app.UseOAuthBearerAuthentication(OAuthBearerOptions);

}

Приведенный выше код ничем не отличается от сотен других примеров, которые я просматривал в течение нескольких дней.

Все это прекрасно работает, когда я использую свой бесплатный Azureэкземпляр (через MSDN моей компании) - я могу аутентифицироваться, токен возвращается из Azure, webapi может декодировать его и проверять, и он продолжается.

Моя проблема возникает, когда я пытаюсь выполнить это на экземпляре P1 Azure моего клиента -Я могу аутентифицироваться, получить токен обратно, но мой webapi не декодирует токен.Насколько я вижу, ошибок в журнале нет.

Главное, что я могу видеть в данный момент, - это когда я получаю токен Azure и декодирую его с помощью jwt.io, я вижу "x5t" и«детские» ценности.Основываясь на другой информации, которую я нашел в сети, я смогу получить последние ключи от https://login.microsoftonline.com/common/discovery/keys и найти там значения "x5t" и / или "kid" .... ноЯ не могу

Возможно ли это?Что может привести к созданию токена с ключами, отличными от общих?Это элемент конфигурации при регистрации приложения в Azure?Нужно ли добавлять дополнительные настройки в конфигурацию UseWindowsAzureActiveDirectoryBearerAuthentication в веб-интерфейсе?

Все токены v1

Answer 1

Ответ для любого, кто столкнется с этой темой в будущем ... вероятно ошибка новичка:)

В моем случае я обнаружил, что администратор на стороне Azure зарегистрировал мое приложение, используя опцию «Корпоративные приложения» на своем портале Azure ПЕРЕД редактированием манифеста и т. Д. В области «Регистрация приложений». В соответствии со службой поддержки Microsoft, это должно быть сделано наоборот - сначала зарегистрируйтесь в регистрации приложений, а затем перейдите к корпоративным приложениям (при необходимости). Выполнение действий в таком порядке означает, что клиент Azure затем генерирует токены и подписывает их «общими» ключами, а не настраиваемым ключом, который получает приложение Enterprise.