Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
MSAL Angular fournit MsalGuard, une classe que vous pouvez utiliser pour protéger les itinéraires et exiger l’authentification avant d’accéder à l’itinéraire protégé. Ce document fournit plus d’informations sur la configuration du MsalGuard et les points à prendre en compte lors de son utilisation.
MsalGuard est une classe pratique que vous pouvez utiliser pour améliorer l’expérience utilisateur, mais elle ne doit pas être utilisée pour la sécurité. Les attaquants peuvent potentiellement contourner les gardes côté client et vous devez vous assurer que le serveur ne retourne pas de données auxquelles l’utilisateur ne doit pas accéder.
Vous pouvez également nécessiter une garde de route pour répondre à des besoins spécifiques. Nous vous encourageons à écrire votre propre garde si MsalGuard ne répond pas à tous ces besoins.
Configurations
Configuration du MsalGuard dans app.module.ts et app-routing.module.ts
Le MsalGuard peut être ajouté à votre application en tant que fournisseur dans app.module.ts, avec sa configuration associée. Les imports incluent une instance de MSAL, ainsi que deux objets de configuration spécifiques à Angular. Le deuxième argument est un MsalGuardConfiguration objet, qui contient les valeurs pour interactionType, un facultatif authRequestet un objet facultatif loginFailedRoute.
Le MsalGuard est ensuite utilisé pour protéger les routes dans app-routing.module.ts. L’exemple de code ci-dessous illustre l’ajout de MsalGuard à la route Profile. La protection de l’itinéraire Profile signifie que même si un utilisateur ne se connecte pas à l’aide du Login bouton, s’il tente d’accéder à l’itinéraire Profile ou cliquez sur le Profile bouton, il MsalGuard invite l’utilisateur à s’authentifier par le biais d’une fenêtre contextuelle ou d’une redirection avant d’afficher la Profile page.
Votre configuration peut ressembler à ce qui suit. Consultez notre documentation de configuration sur d’autres façons de configurer MSAL Angular pour votre application et les sections ci-dessous pour plus d’informations sur l’objet et les interfaces pour le MsalConfiguration routage.
// app.module.ts
import { NgModule } from '@angular/core';
import { HTTP_INTERCEPTORS, HttpClientModule } from "@angular/common/http";
import { MsalModule, MsalRedirectComponent, MsalGuard } from '@azure/msal-angular'; // Import MsalInterceptor
import { InteractionType, PublicClientApplication } from '@azure/msal-browser';
import { AppComponent } from './app.component';
import { AppRoutingModule } from './app-routing.module';
@NgModule({
declarations: [
AppComponent,
],
imports: [
MsalModule.forRoot( new PublicClientApplication({
// MSAL Configuration
}), {
// MSAL Guard Configuration
interactionType: InteractionType.Redirect,
authRequest: {
scopes: ['user.read']
},
loginFailedRoute: '/login-failed'
}, {
// MSAL Interceptor Configurations
}),
AppRoutingModule
],
providers: [
// ...
MsalGuard
],
bootstrap: [AppComponent, MsalRedirectComponent]
})
export class AppModule { }
// app-routing.module.ts
import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';
import { HomeComponent } from './home/home.component';
import { ProfileComponent } from './profile/profile.component';
import { MsalGuard } from '@azure/msal-angular';
const routes: Routes = [
{
path: 'profile',
component: ProfileComponent,
canActivate: [MsalGuard]
},
{
path: '',
component: HomeComponent
},
];
@NgModule({
imports: [RouterModule.forRoot(routes)],
exports: [RouterModule]
})
export class AppRoutingModule { }
Type d’interaction
La définition du type d’interaction détermine comment le MsalGuard invitera l’utilisateur à se connecter de manière interactive. Le InteractionType peut être importé depuis @azure/msal-browser et être défini sur Popup ou Redirect.
AuthRequest facultative
Le facultatif authRequest est une option avancée qui n’est pas requise. Toutefois, nous vous recommandons de définir authRequest sur le MsalGuardConfiguration avec scopes afin que le consentement puisse être obtenu à l'avance pour les étendues. Si le consentement pour scopes n’est pas accordé d’emblée, les portées peuvent être obtenues de manière incrémentielle. Cela peut entraîner la présentation d’un dialogue de consentement à l’utilisateur de votre application plusieurs fois.
L'obtention préalable du consentement pour les étendues est illustrée dans les exemples de code ci-dessus ainsi que dans nos exemples.
Tous les paramètres possibles de l’objet de requête sont disponibles ici : PopupRequest et RedirectRequest.
Route d'échec de connexion
La loginFailedRoute chaîne peut être définie sur MsalGuardConfiguration. Le MsalGuard redirigera vers cette route si la connexion est requise et échoue.
Consultez l’exemple Angular pour obtenir des exemples d’implémentation dans le module de configuration et de routage des applications.
Notez que la redirection en cas d’échec n’est pas disponible pour les applications Angular 9 qui utilisent l’interface CanLoad en raison des différences de type de base.
Interfaces
En plus de canActivate, MsalGuard implémente également canActivateChild et canLoad, et ceux-ci peuvent être ajoutés à vos définitions de routage dans app-routing.module.ts. Vous pouvez voir ces éléments utilisés dans notre ancien exemple d’application MSAL Angular v2 Angular 11, ainsi que ci-dessous. Pour plus d’informations sur les interfaces, consultez la documentation Angular.
const routes: Routes = [
{
path: 'profile',
canActivateChild: [MsalGuard],
children: [
{
path: '',
component: ProfileComponent
},
{
path: 'detail',
component: DetailComponent
}
]
},
{
path: 'lazyLoad',
loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule),
canLoad: [MsalGuard]
},
];
Considérations relatives à l’utilisation de MSAL Guard
Utilisation de MSAL Guard sur la page d’accueil
La définition de MsalGuard la page initiale est notre recommandation si vous souhaitez que les utilisateurs soient invités à se connecter lorsqu’ils atteignent votre application. Nous ne recommandons pas d'appeler login dans le ngOnInit de app.component.ts, car cela peut entraîner une boucle de redirections.
Nos recommandations supplémentaires dépendent de votre stratégie de routage et sont disponibles dans les sections ci-dessous.
Utilisation du garde MSAL avec le routage par chemin
Lorsque vous utilisez PathLocationStrategy et des redirections avec votre application Angular, nous vous recommandons d’utiliser une route dédiée aux redirections, ce qui permet d’éviter les boucles. Cette route doit également être votre redirectUri et ne doit pas être protégée par le MsalGuard.
const routes: Routes = [
{
path: 'profile',
component: ProfileComponent,
canActivate: [MsalGuard]
},
{
// Dedicated route for redirects
path: 'auth',
component: MsalRedirectComponent
},
{
path: '',
component: HomeComponent
}
];
Pour permettre aux utilisateurs de se connecter lorsqu’ils arrivent sur votre application, lors de l’utilisation de PathLocationStrategy, nous vous recommandons :
- Configuration de
MsalGuardsur votre page initiale - Définissez votre
redirectUrivaleur sur'http://localhost:4200/auth' - Ajouter un chemin
'auth'à vos routes, en définissantMsalRedirectComponentcomme composant (cette route ne doit pas être protégée par leMsalGuard) - Vérifier que
MsalRedirectComponentest initialisé - Facultatif : ajout
MsalGuardà tous vos itinéraires si vous souhaitez que tous vos itinéraires soient protégés
Notre exemple de modules Angular utilise PathLocationStrategy et montre comment protéger des routes avec le MsalGuard.
Utiliser MSAL Guard avec le routage par hachage
Lorsque vous utilisez HashLocationStrategy avec votre application Angular, nous vous recommandons vivement de définir des routes factices (comme /code) dans votre app-routing.module.ts afin d’éviter de déclencher le routeur Angular lorsque Microsoft Entra ID renvoie la réponse contenant le code d’autorisation dans le fragment d’URL, faute de quoi vous risquez de rencontrer des problèmes lors de la finalisation de l’authentification. Ces routes fictives ne doivent pas être protégées par le MsalGuard et ne doivent pas pointer vers un composant qui déclenche une interaction ou effectue des appels d’API protégés au chargement de la page.
const routes: Routes = [
{
path: 'profile',
component: ProfileComponent,
canActivate: [MsalGuard]
},
{
// Needed for hash routing
path: 'code',
component: HomeComponent
},
{
path: '',
component: HomeComponent
}
];
Le redirectUri dans la configuration MSAL doit également être défini sur la page d’accueil.
Pour permettre aux utilisateurs de se connecter lorsqu’ils arrivent sur votre application, lors de l’utilisation de HashLocationStrategy, nous vous recommandons :
- Configuration de
MsalGuardsur votre page initiale - Ne pas définir le
MsalGuardsur les routes factices (par exemple/code,/error) - Vérifier que
MsalRedirectComponentest initialisé - Facultatif : ajout
MsalGuardà tous les autres itinéraires si vous souhaitez que tous vos itinéraires soient protégés
Consultez notre ancien exemple MSAL Angular v2 Angular 11, qui utilise HashLocationStrategy et montre comment protéger des routes avec MsalGuard.
Modifications entre msal-angular v1 et v2
-
Configuration :
MsalAngularConfigurationa été déconseillée et ne fonctionne plus. La configuration de l’objetMsalGuardest maintenant effectuée via leMsalGuardConfiguration. -
Interfaces :
MsalGuardimplémente désormaisCanActivateChildetCanLoad, en plus deCanActivate. Pour plus d’informations, consultez la section ci-dessusInterfaces. -
Redirection en cas d’échec :
MsalGuardla configuration dispose désormais d’unloginFailedRouteconfigurable. Consultez la section ci-dessus sur leloginFailedRoutepour plus de détails.