access_token совпадает с id_token при попытке получить токен доступа с помощью ADAL.js AuthenticationContext?

Я аутентифицирую свое одностраничное приложение (Angular4) с помощью Azure AD и использую Adal.js для него. На странице входа в систему я нажимаю кнопку, которая перенаправляет в Microsoft AAD и при успешном входе в систему перенаправляет обратно на домашнюю страницу приложения и получает id_token и информация о пользователе от JWT.

мне нужно access_token для внутреннего доступа к API, который я пытаюсь получить через ADAL AuthenticationContext"s getCachedToken() метод и отправка clientId в качестве параметра:

this.context.getCachedToken(this.configService.AdalConfig.clientId)

Но этот метод возвращает тот же токен, который хранится в хранилище сессии, как id_token (adal.idtoken), Он в основном создает новый элемент в хранилище сеанса с помощью связанного ключа, который имеет то же значение, что и id_token

adal.access_token.key + clientId = id_token

например: adal.access_token.key239f6fc7-64d2-3t04-8gfd-501efc25adkd = <id-token-value>,

Я также пытался получить access_token с AuthenticationContext.acquireToken() метод, но это тоже дало id_token назад.

Куда я иду не так?

РЕДАКТИРОВАТЬ: размещение кода. Я вызываю функцию login(), и после успешного входа в систему, пытаясь получить токен доступа на домашней странице через get accessToken() собственность собственности в adal.config.ts,

config.service.ts

import { Injectable } from '@angular/core';

@Injectable()
export class ConfigService {
  constructor() {}
  public get AdalConfig(): any {
    return {
      tenant: 'common',
      clientId: <application-id>,
      redirectUri: window.location.origin + '/',
      postLogoutRedirectUri: window.location.origin + '/'
    };
  }
}

adal.service.ts

import { ConfigService } from './config.service';
import { Injectable } from '@angular/core';
import { adal } from 'adal-angular';
let createAuthContextFn: adal.AuthenticationContextStatic = AuthenticationContext;

@Injectable()
export class AdalService {
  private context: adal.AuthenticationContext;
  constructor(private configService: ConfigService) {
    this.context = new createAuthContextFn(configService.AdalConfig);
  }

  login() {
    this.context.login();
  }

  logout() {
    this.context.logOut();
  }

  handleCallback() {
    this.context.handleWindowCallback();
  }

  public get userInfo() {
    return this.context.getCachedUser();
  }

  public get accessToken() {
    return this.context.getCachedToken(this.configService.AdalConfig.clientId);
    // return this.context.acquireToken(this.configService.AdalConfig.clientId, function(message, token, response) {
    //   console.log(message, token, response);
    // });
  }

  public get isAuthenticated() {
    return this.userInfo && this.accessToken;
  }
}
Источник

1 ответ

Решение

На самом деле, после небольшого чтения оказалось, что для подключения SPA к Azure AD требуется поток неявного предоставления OAuth 2.0. Документация Microsoft гласит:

В этом случае, когда пользователь входит в систему, клиентский интерфейс JavaScript использует библиотеку проверки подлинности Active Directory для JavaScript (ADAL.JS) и неявную привилегию авторизации для получения токена идентификатора (id_token) из Azure AD. Токен кэшируется, и клиент присоединяет его к запросу в качестве токена-носителя при совершении вызовов к своему внутреннему интерфейсу Web API, который защищен с помощью промежуточного программного обеспечения OWIN.

Итак, это id_token Сам, что мне нужно отправить на серверные API, которые в свою очередь могут быть проверены и использованы. Более подробная информация о валидации приведена здесь:

Простого получения id_token недостаточно для аутентификации пользователя; Вы должны проверить подпись id_token и проверить утверждения в токене в соответствии с требованиями вашего приложения. Конечная точка v2.0 использует веб-токены JSON (JWT) и криптографию с открытым ключом, чтобы подписывать токены и проверять их действительность.

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

Источник

Я столкнулся с такой же проблемой, как ваша, когда пытался отправить токен в конечную точку.Net Core API. Он работал для меня, когда я послал маркер из adal.access.token.key узла, на sessionStorage.

Использование значений токенов adal.access.token.key или adal.idtoken (они одинаковы) у меня не сработало.

Действительный токен на узле adal.access.token.key.

Источник
Другие вопросы по тегам