Incorrect Azure passport library used

Expected Behavior

We should be able to generate a jwt bearer token to be used in other applications.

Current Behavior

The token we currently generate labeled and documented as Azure is only usable for Microsoft Graph API.

Possible Solution

This should be do-able by making use of passport-azure-ad, which apparently uses msal.js, a library that we have used in the past and it seemed to work correctly.

Steps to Reproduce

Set up Azure

You will need two apps registered in Azure, one for Backstage (App1) and one for the app that you’re trying to interact with (App2). In App2 you will need a custom scope, that you will then add in App1 as a delegated scope.

Set up the code

I won’t show any backend code since this issue can be reproduced without doing the HTTP request.

But this is basically what you need:

private readonly authApi: OAuthApi;

  public constructor() {
    this.authApi = useApi(microsoftAuthApiRef);
  }

  public async testApiCall(): Promise<void> {
    const token = await this.getToken();
    console.log(`Token: ${token}`);
    await fetch('https://localhost:5001/WeatherForecast', {
      headers: new Headers({
        Authorization: `Bearer ${token}`,
      }),
    });
  }


  public async getToken(): Promise<string> {
    return this.authApi.getAccessToken(
      [`api://<APP-ID>/CustomScope.Read`],
    );
  }

All we care for here is getToken(), which is supposed to return a token that is usable in the context of that app id, but if you decode the token via jwt.io you will be able to notice that the aud (Audience) for that token is set to 00000003-0000-0000-c000-000000000000 and not my <APP-ID>, which apparently means that the token is only usable when used against Graph API.

Context

We are basically trying to authenticate and authorise using the token generated by Backstage against other applications, that also use Azure AD. The bigger problem is that this is also documented as Azure Authentication, which can make it a bit confusing.

[freben]

I think the main problem here is lack of time. I read up a bit on the excellent post from @kmikko now and this does sound like it might take some poking at our internals to support it. Worst case, making several providers; one per scope (e.g. something like a msgraphAuthApi separate from microsoftAuthApi so to speak, with explicit limitations in how they handle scopes).

Pinging @Rugvip

[Rugvip]

Yep thinking that a separate msgraphAuthApi or something like that is where we need to go with this in the end. One that doesn’t have the conflicting default scopes. We’d need to duplicate the auth provider in the backend too, since session and scopes are persisted per provider. Would expect it to just be a duplicate registration of the provider factory in the backend though, not a complete separate implementation.