Этот метод предназначен для получения кода авторизации, который, насколько я знаю, соответствует этому потоку авторизации , и параметры запроса для него задокументированы там.
Вы можете увидеть, как ADAL анализирует и использует параметры запроса из источника на GitHub . Если вы попытаетесь переопределить параметр запроса, который уже указан библиотекой (например, redirectUri), он выдаст исключение.
Одним из примеров параметра запроса, который вы можете успешно переопределить, является domain_hint
Предоставляет подсказку об арендаторе или домене, который пользователь должен использовать для входа. Значение domain_hint является зарегистрированным доменом для арендатора. Если клиент объединен с локальным каталогом, AAD перенаправляет на указанный сервер федерации клиента.
Большинство других параметров запроса, по-видимому, уже используются библиотекой и либо жестко заданы библиотекой, либо указаны пользователем в другом месте.
Есть также некоторая документация для этого параметра в ADAL wiki
extraQueryParameters (необязательно) позволяет разработчикам приложений предоставлять дополнительные параметры конечным точкам STS. Это могут быть подсказки или своего рода точка расширения для параметров, не предоставляемых напрямую через API. Это разделенная запятыми строка ключей / значений, разделенных амперсандом: "key1=value1&key2=value2". - Обратите внимание, что ADAL.NET также проверяет, существует ли конкретная переменная среды (
ExtraQueryParameter) и добавляет ли она дополнительный параметр запроса к каждому запросу к конечной точке STS.
Что может указывать на то, что это более полезно при использовании пользовательского STS вместо AAD напрямую