Да, я согласен с тем, что согласно новым правилам неявный поток не рекомендуется. В настоящее время ADAL js использует неявный поток OAuth 2.0 и не возвращает токен обновления по соображениям безопасности (токены обновления имеют более длительный срок службы, чем токены доступа, и поэтому более опасны для злоумышленников).
Он предназначен для возврата идентификатора токена, когда ресурс, для которого запрашивается токен, совпадает с клиентским приложением. Когда ID-токен возвращается, он кэшируется библиотекой.
Поэтому, когда мы используем authenticationContext.acquireToken (resource, callback) , это позволяет приложению получать токены в режиме без вывода сообщений, не запрашивая пользователя снова. ADAL js использует скрытый Iframe для отправки запроса токена в Azure AD.
Но чтобы использовать поток PKCE, мы можем сделать http-вызов к конечной точке https://login.microsoftonline.com/tenant_id/outh2/authorize, передав code_challenge вместе с другими параметрами в теле и получив код авторизации. И используйте этот код и сделайте вызов конечной точке https://login.microsoftonline.com/tenant_id/outh2/token, передав code_verifier вместе с другими параметрами в теле и получив токен.
Если вы используете SPA и не имеете внутренних компонентов или намереваетесь вызвать веб-API через JavaScript, используйте поток неявного предоставления OAuth 2.0.
Но если у вас есть компонент бэкэнда и вы используете API из кода бэкэнда, то неявный поток не подходит. В этом случае вы можете использовать поток предоставления кода авторизации OAuth2.0 или поток предоставления полномочий клиента OAuth2.0, он предоставляет возможность получения токенов, которые отражают разрешения, назначенные самому приложению.