@azure/msal-angular works with Angular 17

[muhamedkarajic]

Core Library

MSAL.js (@azure/msal-browser)

Wrapper Library

MSAL Angular (@azure/msal-angular)

Public or Confidential Client?

Public

Description

Please update it to angular 17, I noticed that the current version dosent work with esmodule builder.

Source

External (Customer)

[mlz11]

We are waiting for an answer on the following issue 🥶

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/6691

[nimbusparis]

When the update will be available? Angular 17 was released on 6 of November, it's not acceptable that a component like MSAL is not updated at release time and therefore 1 month after!

[EmLauber]

I don't have a timeline yet for Angular 17 support, but we are tracking and aware of it. Thank you for expressing your interest.

[mrivero2020]

To those updating @azure/msal-angular: Can you explain the typical timeline for updates to this package? Is it that the team must wait for Angular to release a version for the team to start upgrading @azure/msal-angular to catch up to Angular? It is fine if that is the case, but we need to know for planning purposes. It seems to me that this package is upgraded "months" after Angular releases a new version and knowing that on average this product will lag "x number of months" will help those of us depending on this component to plan and provide correct ETAs to our stakeholders.

[talgershman]

alot of project will need to updage to Angular 17, as it is a major update to framework. (improves so much things that developers are waiting for years). Please don't block us from upgrading and put in the near road map, i don't think it will be a major update from your end as most of the changes are related to change detection.

[muhamedkarajic]

Any updates on this? I see today we have a 3.0.10 but it dosent seem documentation is updated it says still v15 and v16. What makes angular 17 so hard to update?

[EmLauber]

I appreciate people adding more details on why this is important to their project. I have no new updates. We are aware and have this work in our backlog. To add more context, each major framework version requires evaluating the changes and balancing whether those are backwards compatible for MSAL versions or require our own major version bump. That is why we as the MSAL maintainers can't always predict how much time it takes to add the latest framework support.

[JaimeStill]

In case it's helpful to anyone, I spent a bit of time working to get msal-angular working with Angular 17 before finding this issue. I captured my notes in the readme of my angular-identity-spa repository.

I'm certain that once these kinks are ironed out in migrating to Angular 17, this will be a very clean integration. A big thanks to the MSAL.js team for all of the work that's gone into supporting so many different platforms, and particularly keeping Angular in the mix.

[OWS-thinhpv]

I need @azure/msal-... for v17, because according to the appropriate roadmap, I hope @azure/msal-... will make a plan to update v17 for all devs around the world.

[smg-bg]

Any roadmap / ETA will greatly help our internal release cadance 🔢

[KarolZirex]

Is it a joke that Microsoft has not yet supported Angular 17 after three months?

[umberto-titola]

It's working for me with Angular 17. I don't understand what the problem is. this is my configuration.. I added the redirect inside the initializer it works fine, I put the token in the api.. I don't understand. What's the problem, maybe I missed something? It seems to work very well to me

  bootstrapApplication(AppComponent,
    {
      providers: [
        provideHttpClient(withInterceptorsFromDi()),
        provideRouter(routes),

        {
          provide: HTTP_INTERCEPTORS,
          useClass: MsalInterceptor,
          multi: true
        },
        {
          provide: MSAL_INSTANCE,
          useFactory: () => MSALInstanceFactory(<MsalConfig>config)
        },
        {
          provide: MSAL_GUARD_CONFIG,
          useFactory: MSALGuardConfigFactory
        },
        {
          provide: MSAL_INTERCEPTOR_CONFIG,
          useFactory: () => MSALInterceptorConfigFactory(<BackendResourcesType>config?.backendResources),
        },
        MsalService,
        MsalGuard,
        MsalBroadcastService,
        {
          provide: APP_INITIALIZER,
          useFactory:app_init,
          multi: true,
          deps: [MsalService,AppService],
        },
        provideAnimations()
      ]
    },
  )

this is my package,json

 "@angular/animations": "^17.0.0",
    "@angular/cdk": "^17.1.0",
    "@angular/common": "^17.0.0",
    "@angular/compiler": "^17.0.0",
    "@angular/core": "^17.0.0",
    "@angular/forms": "^17.0.0",
    "@angular/material": "^17.1.0",
    "@angular/material-moment-adapter": "^17.1.1",
    "@angular/platform-browser": "^17.0.0",
    "@angular/platform-browser-dynamic": "^17.0.0",
    "@angular/router": "^17.0.0",
    "@azure/msal-angular": "^3.0.9",
    "@azure/msal-browser": "^3.6.0",
    "@azure/web-pubsub-client": "^1.0.0-beta.3",
    "rxjs": "~7.8.0",
    "tslib": "^2.3.0",
    "zone.js": "~0.14.2"

tsconfig.json

{
  "compileOnSave": false,
  "compilerOptions": {
    "outDir": "./dist/out-tsc",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "noImplicitOverride": true,
    "noPropertyAccessFromIndexSignature": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "allowSyntheticDefaultImports":true,
    "esModuleInterop": true,
    "sourceMap": true,
    "declaration": false,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "ES2022",
    "module": "ES2022",
    "useDefineForClassFields": false,
    "lib": [
      "ES2022",
      "dom"
    ]
  },
  "angularCompilerOptions": {
    "enableI18nLegacyMessageIdFormat": false,
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  }
}

[smg-bg]

@umberto-titola Actually it seems to work for 17.0, but not 17.1. I sitll don't understandand, but I'm not an expert, why...

[wy193777]

I made it work on 17.1. Basically is Subscribing to handleRedirectObservablemanually.

In your app.component.ts,

import { Component, OnInit } from '@angular/core';
import { MsalBroadcastService, MsalService } from '@azure/msal-angular';
import { AuthenticationResult } from '@azure/msal-browser';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css']
})
export class HomeComponent implements OnInit {
  account: WritableSignal<AccountInfo | null> =  #signal(null);

  constructor(private authService: MsalService) { }

  ngOnInit(): void {
    this.authService.handleRedirectObservable().subscribe({
      next: (result: AuthenticationResult) => {
        // Perform actions related to user accounts here
        console.log('Redirect success', result);
            this.account.set(this.authService.instance.getActiveAccount());
            this.cdr.detectChanges();
      },
      error: (error) => console.log(error)
    });
  }

}

Basically I copied lots of code from @JaimeStill 's repo but substitute the part that using this.msalBroadcastService.inProgress$.pipe().subscribe() to handleRedirectObservable.

In case it's helpful to anyone, I spent a bit of time working to get msal-angular working with Angular 17 before finding this issue. I captured my notes in the readme of my angular-identity-spa repository.

I'm certain that once these kinks are ironed out in migrating to Angular 17, this will be a very clean integration. A big thanks to the MSAL.js team for all of the work that's gone into supporting so many different platforms, and particularly keeping Angular in the mix.

My project is still in the very beginning phase so I'm not sure what other difficulties will appear.

[umberto-titola]

I made it work on 17.1. Basically is Subscribing to handleRedirectObservablemanually.

In your app.component.ts,

import { Component, OnInit } from '@angular/core';
import { MsalBroadcastService, MsalService } from '@azure/msal-angular';
import { AuthenticationResult } from '@azure/msal-browser';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css']
})
export class HomeComponent implements OnInit {
  account: WritableSignal<AccountInfo | null> =  #signal(null);

  constructor(private authService: MsalService) { }

  ngOnInit(): void {
    this.authService.handleRedirectObservable().subscribe({
      next: (result: AuthenticationResult) => {
        // Perform actions related to user accounts here
        console.log('Redirect success', result);
            this.account.set(this.authService.instance.getActiveAccount());
            this.cdr.detectChanges();
      },
      error: (error) => console.log(error)
    });
  }

}

Basically I copied lots of code from @JaimeStill 's repo but substitute the part that using this.msalBroadcastService.inProgress$.pipe().subscribe() to handleRedirectObservable.

In case it's helpful to anyone, I spent a bit of time working to get msal-angular working with Angular 17 before finding this issue. I captured my notes in the readme of my angular-identity-spa repository. I'm certain that once these kinks are ironed out in migrating to Angular 17, this will be a very clean integration. A big thanks to the MSAL.js team for all of the work that's gone into supporting so many different platforms, and particularly keeping Angular in the mix.

My project is still in the very beginning phase so I'm not sure what other difficulties will appear.

I'm doing it inside app initializer to do it before I get to bootstrap the app.component

[Erbenos]

I have had an issue when the MsalInterceptor has been swallowing and "hanging" (they weren't even fired) requests made via HttpClient during app initialization (aka.: procedures registered via APP_INITIALIZER). Had to subscribe to authService.handleRedirectObservable() too, upon which the Interceptor let the requests through.

[timothytavarez]

msal-angular is now one major release and two minor versions behind the product it should be supporting.

Angular 17 was released 95 days ago on 2023-11-08. Angular 17.2 is being released this week. I cannot upgrade our applications despite every dependency screaming at me to resolve issues because msal-angular is blocking us.

The maintainers behind msal-angular are obviously not resourced appropriately to support this product. Every time I discuss authentication issues with other CTOs, I now have to qualify my statements regarding Microsoft Entra / B2C.

[smg-bg]

@EmLauber any clarification why this is taking so long? Are you understaffed? Are there any major changes that need to be made on you side and if so what are those?

[zameb]

I am not sure what the problem is, but basically, when I started to work with an Angular 17 project, I could not find examples to make it work with Msal. So, I thought Msal was not ready yet for the current Angular version. I'm not sure if it is other's case.

After a lot of error and trial, I have a running project and there were several things to tweak, but currently it is working. I'm summarizing the components that make it possible in the following repo: https://github.com/zameb/Msal.Ng17/tree/main

Basically, it has a factory to connect to msal, login and logout button components, an interceptor to add the token to the API calls and a guard to protect resources with authz requirements.

What we don't have yet is the Silent Token renewal flow, but I will update this repo as we advance or improve our project.

I'm also sharing this to get feedback if I'm missing something.

And... I hope it does not broke too much when Msal is finally up-to-date.

[talgershman]

@tnorling @EmLauber Can we get some info about this issue ? when do you think you will start to develop this?

[EmLauber]

I appreciate everyone's feedback that has attempted their own integrations for Angular 17 and MSAL. We have an engineer assigned this quarter (CY24Q1) to adding Angular 17 support, dependent on their current assigned work finishing. I will update this issue with any new developments.

[JamesInDenver]

@EmLauber Can you speak to the ongoing ability to keep up with Angular's release cycle (2 major versions a year)?

[Devvox93]

I second @JamesInDenver's question above. I would expect from Microsoft, a big tech company, to provide first-class support for this MSAL library for Angular, since the combination .NET/Angular is used a LOT by big organizations. Angular provides pre-releases like alpha, beta. I would expect the MSAL Angular team to be following this closely and work on updates early, using said pre-releases, so that this library can release support for the next major version close to the same day or week instead of MONTHS after a major Angular release. It's such an important package for so many companies...

[nimbusparis]

I second @JamesInDenver's question above. I would expect from Microsoft, a big tech company, to provide first-class support for this MSAL library for Angular,

Especially when AZ-204 training advertise on this package to handle authentication thru Microsoft Entra ID...

[mrivero2020]

By now we are beating a dead horse, but it worth mentioning that that on npmjs.com, under Version Support, the following "false" advertising is displayed: "At a minimum, @azure/msal-angular will follow the support schedule of the main Angular project. We may continue to support certain versions of Angular that are not under Active or LTS support from the main Angular project on a version-by-version basis, as defined below."

Clearly a single engineer is not enough to keep up with the changes in Angular. The project managers at Microsoft must realize that they are pushing developers to drop Angular and favor other frameworks, for which Microsoft does have its support up to date. That this happens one time is understandable but twice in a row should require changes, starting with whoever owns this product inside Microsoft.

[Flywheel]

"I would expect from Microsoft, a big tech company, to provide first-class support for this MSAL library for Angular, since the combination .NET/Angular is used a LOT by big organizations."

It's a safer bet to expect the ghosting will continue.

[JaimeStill]

This issue has not been ghosted, the assignee @EmLauber has responded well and given a very clear direction for when we can expect this issue to be resolved. If this requirement is so critical for you or your organization that you need it immediately for a non-LTS version of Angular, put in the work yourself and update the package of this open-source library. It's easy to be critical of other peoples' process when all you do is consume the results of their work. Maybe try to remember that these are people supporting this project, not some nameless corporation.

[Flywheel]

This issue has not been ghosted,

Jaime, I appreciate your own code contribution to this issue, which has been a real help to me. Nevertheless, given @EmLauber's comment, "We have an engineer assigned this quarter (CY24Q1) to adding Angular 17 support, dependent on their current assigned work finishing," I take this to mean that Microsoft's support for Angular 17 is explicitly a secondary priority for this quarter because the assigned engineer has more pressing things to do. So be it. To be fair, perhaps my use of the word "ghosting" rhetorically overstates the current state of affairs, but it doesn't feel like Microsoft has shown itself to be a particularly attentive partner at this important stage of the relationship. Please be clear that I'm not intending to berate the people assigned to this project. I'm responding to the evident corporate decision to leave them so under-resourced.

[mrivero2020]

Jaime, I feel I must push back on your statement "the assignee @EmLauber has responded well and given a very clear direction for when we can expect this issue to be resolved". Perhaps I am in the wrong and I missed some update, but as far as I can tell, we have no clue of an ETA as of February 28th, 2024. When will @azure/msal-angular support Angular 17? If you do know an approximate timeline please share it with the rest of the group, as it will reduce anxiety over this issue. Will it be ready in March? or April? or before Angular 18 is released in May? Saying that a resource will work on it "dependent" on them finishing other assigned work first does not constitute an ETA at all. To the contraire, it is a very deflating statement that makes anyone using this library to start researching alternatives.

[zameb]

I may be completely wrong, but I expect, from a big company, to add resources as needed... Unless it's not an important issue. It's not criticizing your individual job. Apart from that, would not like to complete a bitter lesson here: don't use msal if you're not using an LTS Angular version... But it's better to know and have it clear.

[Erbenos]

Agree with @JaimeStill.

To be honest I am just amazed at the entitlement here. This is open source project, anyone can freely contribute, as far as I know there is no obligation owed to anyone.

[JaimeStill]

@mrivero2020:

We have an engineer assigned this quarter (CY24Q1) to adding Angular 17 support.

You can expect Angular 17 support in Q1 of this year. To me, that indicates by the end of March.

[Flywheel]

Agree with @JaimeStill.

To be honest I am just amazed at the entitlement here. This is open source project, anyone can freely contribute, as far as I know there is no obligation owed to anyone.

Fair enough. My decision to use ADB2C for an Angular frontend, Azure-hosted backend project was based on the evidently mistaken assumption that MSAL would receive timely support from Microsoft.

[crhama]

Agree with @JaimeStill.

To be honest I am just amazed at the entitlement here. This is open source project, anyone can freely contribute, as far as I know there is no obligation owed to anyone.

I was looking forward to using Azure AD. If this is how you see things, maybe an alternative will be welcomed.

[ajm0803]

Is there any update on this? Is a release Mar/2024 still going to happen?

[bjorn-einar-bjartnes-4ss]

Agree with @JaimeStill.

To be honest I am just amazed at the entitlement here. This is open source project, anyone can freely contribute, as far as I know there is no obligation owed to anyone.

There is a claim from Microsoft that they will support the release cycle of Angular. https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular#version-support

[ajm0803]

Thank you, sorry I should of been more specific in my question, for Angular 17 msal is currently not working, I am just wanting to know if the new version which was previously advised will be available in mar 2024, is going to be delivered. If not I may have to downgrade our software to angular 16.

[muhamedkarajic]

Thank you, sorry I should of been more specific in my question, for Angular 17 msal is currently not working, I am just wanting to know if the new version which was previously advised will be available in mar 2024, is going to be delivered. If not I may have to downgrade our software to angular 16.

I'm also interested in this cause I think the new esmodule feature from Angular is not working with that library. As I posted the screenshots I get a couple of errors. I think you just need to republish the package with the new Angular version and it will be fine.

[EmLauber]

Thanks everyone for the feedback. We do take it seriously and I appreciate you taking the time to provide it.

Our engineer has started the Angular 17 work. I will update here once it is complete.

[Viltersten]

...I am just amazed at the entitlement here. This is open source project, anyone can freely contribute...

In my opinion, you shouldn't be. What you see is not entitlement but surprise and desperation. It's not really just an open source project and can't reasonably be compared to small, home-brewed packages available. This one is supporting and supported by major players in the industry. Nobody's bashing the individuals here. Huge companies earn a lot of money based on being the preferred and reliable choice for developers. With that comes responsibility to be proactive. Being open-source mustn't be an excuse for poor quality.

I'd also like to point out that the remark: anyone can freely contribute is technically correct but practically flawed. It's ridiculous to expect that the major portion of devs using the package have ability, competence or capacity to contribute. In some parts of the world, people struggle to support their families not having time to contribute (not me, I'm privileged, not bright enough, though). Please be respectful of others' limitations. Anyone may contribute. True. But can and freely is a stretch.

In my opinion, it's better to admit: yes, we dropped the ball on Angular 17 and simply learn from it. My hopes are that MSAL will be ready for Angular 18 in a couple of month and we'll forget about the sad 17th. :)

[Viltersten]

@mrivero2020:

We have an engineer assigned this quarter (CY24Q1) to adding Angular 17 support.

You can expect Angular 17 support in Q1 of this year. To me, that indicates by the end of March.

Hopefully, the update will arrive in an egg brought by the Easter Bunny. Would be great to bury the gazillion of PBIs waiting on our board.

I wonder if the work for MSAL compatible with Angular 18 has already started and is progressing. My hopes are that whatever got the support stuck at v16 will be eliminated for v17 and v18 simultaneously. Maybe it's the same set of issues, even. In fact, I'd target v18 from start. (Somehow, I feel not many dev will favor v17 anyway...)

[mrivero2020]

Can we have an update of when this product will support Angular 17? We were told Q1 was the target date, but we just entered Q2. Will it be Q2?

[axm]

With Angular 18 around the corner... will MSAL 3.x support it?

[scotthutchison]

I have 3 quite large projects all stalled waiting for this to be released and its starting to hurt these clients. We are well down the path of Angular 17 so we can't unscramble that egg now. We are going to have to look at other options if its not fixed soon. Other than Auth0 is there anything else we can potentially switch to? Our major client project has a hard no on okta so am unsure of where to turn next.

[zameb]

I have 3 quite large projects all stalled waiting for this to be released and its starting to hurt these clients. We are well down the path of Angular 17 so we can't unscramble that egg now. We are going to have to look at other options if its not fixed soon. Other than Auth0 is there anything else we can potentially switch to? Our major client project has a hard no on okta so am unsure of where to turn next.

I understand. I am more or less in the same situation. In the meanwhile, my project is successfully running with MSAL and Angular 17. But it took a lot of effort (trial and error) and we would not have another chance to delay because of the same.

We regret to have used MSAL directly, without interfacing it, it's our fault. Now we are investing time to fix this. Once we have everything in a replaceable service, we will look for another library. My customers cannot be affected again.

Auth0 is also our candidate. You see some inconvenience on it?

[scotthutchison]

I have 3 quite large projects all stalled waiting for this to be released and its starting to hurt these clients. We are well down the path of Angular 17 so we can't unscramble that egg now. We are going to have to look at other options if its not fixed soon. Other than Auth0 is there anything else we can potentially switch to? Our major client project has a hard no on okta so am unsure of where to turn next.

I understand. I am more or less in the same situation. In the meanwhile, my project is successfully running with MSAL and Angular 17. But it took a lot of effort (trial and error) and we would not have another chance to delay because of the same.

We regret to have used MSAL directly, without interfacing it, it's our fault. Now we are investing time to fix this. Once we have everything in a replaceable service, we will look for another library. My customers cannot be affected again.

Auth0 is also our candidate. You see some inconvenience on it?

Auth0 was my pick too - it's a paid service so you can actually rely on the support. It is a good system too and has well documented Angular and .NET integrations that are pretty simple. My major client has quite some negative history with Okta and they gave me a very hard NO. They said they would rather wait and Okta was not something they would entertain. It is now getting to the point where we have to make a call - we have an indeterminite time frame from MSAL where the only obligation is "best endeavours" or we have to look for alternatives that work well with federated Azure AD and B2C. OpenID connect maybe an option? I am jut holding on in the hope that its solved very soon - but my hand is getting slowly forced by 2 other clients also in this holding pattern. Not much else I can do??

[hashpyrit]

I have 3 quite large projects all stalled waiting for this to be released and its starting to hurt these clients. We are well down the path of Angular 17 so we can't unscramble that egg now. We are going to have to look at other options if its not fixed soon. Other than Auth0 is there anything else we can potentially switch to? Our major client project has a hard no on okta so am unsure of where to turn next.

You can still use Azure AD/Entra authentication without using MSAL libraries. I recently removed my dependency on msal-angular and replaced it with a generic angular oauth library (angular-oauth2-oidc). It was relatively straightforward to do and works perfectly fine with Azure.

[EmLauber]

Thanks everyone for your feedback and patience. Our engineer has been diligently working on adding the Angular 17 support, but we've run into a number of issues. Angular 17's new build system includes integrated server-side rendering and prerendering capabilities. As a library meant for single page applications running in a browser, MSAL Angular uses browser-only objects and is not designed to acquire tokens server-side, and has only minimally supported Angular Universal in the past. We have been working on ways around this issue. The standalone sample in particular is proving difficult. Because I know this has been an ongoing issue for the community for a while, we have a few options we are evaluating. We can release support earlier for the regular Angular sample but no standalone sample support. Or we can release later as our engineer continues to investigate the standalone and sever-side rendering issue. Even with more time, we may find that MSAL Angular is incompatible with the SSR capabilities of Angular for a standalone model. I'm inclined for the earlier release option but I am open to feedback from the community that the standalone model & SSR support is worth waiting for.

[Core121]

Definitely on the side of releasing as soon as possible and worrying about all scenarios at a later date. I think delaying much longer will force most to migrate to another library and further give distrust to the reliability of support.

[scotthutchison]

I also selfishly agree with @Core121 - our hand is being forced and there is some serious questions being raised on our 3 projects by clients. I don't fully understand the challenge but I would think it represents a fairly small percentage of the user base? @EmLauber what's your estimated time frame on both scenarios - just roughly as that may put it into a bit clearer context.