Как сделать так, чтобы проверка подлинности Azure AD принимала маркер доступа к строке запроса URL?

Question

Есть ли способ настроить встроенную проверку подлинности Azure AD на прием и заголовка Authorization: Bearer <token>, и строки запроса URL access_token=<token>?

Мне нужно это, чтобы разрешить соединение SingalR WebSocket из браузера.

Мой сценарий

У меня есть серверная часть ASP.Net Core, на которой размещены концентраторы SignalR Core.Сайт размещается в качестве службы приложений Azure с включенной проверкой подлинности Azure AD.

Доступ к REST Apis отлично работает как из приложения .Net, так и с веб-сайта.

Из .Net

Соединение SignalR сПриложение .Net работает нормально и использует websocket.Соединение через веб-сокет устанавливается с помощью следующего HTTP-запроса:

GET https://<url>/hubs/chat?id=rk-Adzl1EWGCv8wsVF5ayg HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: m02nzEFDAFVwCgUPlF2rEA==
Sec-WebSocket-Version: 13
X-Requested-With: XMLHttpRequest
Authorization: Bearer <token>
Host: evotrqhub.evopro-ag.de
Cookie: ARRAffinity=8666c8fbc8cd126e76e2b31c5880dd9c4968a103221108a610b408e12a15fa39

Обратите внимание, что авторизация выполняется с заголовком Authorization: Bearer <token>.

Из браузера

Когда я устанавливаю соединение SignalR из браузера (Chrome или Firefox), соединение через веб-сокет не может быть установлено, и длительный опрос используется в качестве запасного.HTTP-запрос для подключения через веб-сокет:

GET https://evotrqhub.evopro-ag.de/hubs/coilthickness?id=QB5xx4MLGi6uSvVK4QmvZA&access_token=<token> HTTP/1.1
Host: evotrqhub.evopro-ag.de
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost:5000
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: de,en-US;q=0.9,en;q=0.8
Cookie: ARRAffinity=8666c8fbc8cd126e76e2b31c5880dd9c4968a103221108a610b408e12a15fa39
Sec-WebSocket-Key: K4hUR2QFyRxcDKxfoNwn2w==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

Здесь авторизация выполняется с помощью auth_token=<token> параметра запроса url.

Ответ от сервера - перенаправление (код ответа 302) на страницу входа в Azure AD.

Документы SignalR Core рекомендуют использовать JwtBearerEvents OnMessageReceived для разрешения ситуации, но в этом случае проверка подлинности Azure AD приложения-службы Azure отклоняет запрос, прежде чем он может бытьобрабатывается моим кодом пользователя.

Так есть ли способ настроить проверку подлинности AD службы приложений Azure для приема параметра access_token?

Answer 1

Если вы используете клиент JavaScript SignalR, вы можете предоставить метод, который будет возвращать токен доступа, который будет включен в запросы клиента как токен Bearer. Это должно работать независимо от используемого метода транспорта (хотя я сам не пробовал)

Пример из документов (https://docs.microsoft.com/aspnet/core/signalr/configuration?#configure-bearer-authentication):

let connection = new signalR.HubConnectionBuilder()
    .withUrl("/myhub", {
        accessTokenFactory: () => {
            // Get and return the access token.
            // This function can return a JavaScript Promise if asynchronous
            // logic is required to retrieve the access token.
        }
    })
    .build();