Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. OAuth 2 et OpenID Connect
  3. Client Initiated Backchannel Authentication
Extrait - OAuth 2 et OpenID Connect Sécurisez vos applications .Net avec IdentityServer
Extraits du livre
OAuth 2 et OpenID Connect Sécurisez vos applications .Net avec IdentityServer Revenir à la page d'achat du livre

Client Initiated Backchannel Authentication

Présentation

Le Client Initiated Backchannel Authentication ou CIBA est un mode d’authentification qui diffère des modes vus précédemment par le fait que l’application cliente fait une demande d’authentification au SSO, mais celle-ci ne se fait pas en direct via un jeu de redirections comme dans les modes habituels. Ici, le SSO enverra une notification de connexion à l’utilisateur via un canal qui peut être une notification push sur une application mobile, un e-mail, un SMS, etc. Une fois la notification reçue, l’utilisateur pourra s’authentifier. Pendant ce temps, l’application cliente fait de l’attente active (https://fr.wikipedia.org/wiki/Attente_active) pour demander un token au SSO. Tant que l’utilisateur ne s’est pas authentifié, la demande de token revient en erreur. La norme OIDC permet d’autres modes de fonctionnement : le « Ping mode » et le « Push mode ». Ces deux modes utilisent tous deux des callbacks au lieu de faire de l’attente active, mais actuellement ils ne sont pas supportés par IdentityServer.

Ce mode d’authentification est nécessaire pour obtenir l’agrément bancaire Open ID Connect. C’est d’ailleurs le fonctionnement du 3D Secure avec les applications des banques. Le site de e-commerce envoie une demande de paiement à son terminal...

Configurer le SSO

1. Client

Pour implémenter le CIBA, nous allons avoir besoin d’une application cliente qui se connectera en utilisant ce mode de connexion. Dans la classe Seed du SSO, ajoutez après le dernier client enregistré un nouveau client pour le CIBA :

if (!await configurationDbContext.Clients.AnyAsync(client => 
client.ClientId == "A48343E932C14179BBD756F11EB8C4E0"))  
{  
  Client cibaClient = new()  
  {  
    AllowedCorsOrigins = { "https://localhost:5008" },  
    AllowedGrantTypes = GrantTypes.Ciba,  
    AllowedScopes = {  
      IdentityServerConstants.StandardScopes.OpenId,  
      IdentityServerConstants.StandardScopes.Profile,  
      IdentityServerConstants.StandardScopes.Email,  
    },  
    AllowOfflineAccess = true,  
    ClientId = "A48343E932C14179BBD756F11EB8C4E0",  
    ClientSecrets = { new("7CE301D98E6D47C2A399AB0E8A5E740B0034
7F0BDC814B96A7A9A4B9DEED26DC".ToSha256()) },  
    ClientName = "CIBA client Application",  
    PostLogoutRedirectUris = { "https://localhost:5008" },  
    RedirectUris = { "https://localhost:5008/signin-oidc" }  
  };  
  configurationDbContext.Clients.Add(cibaClient.ToEntity());  
} 

2. BackchannelAuthenticationUserValidator

Sur le schéma du flux CIBA, il est indiqué que la deuxième étape est la validation de l’utilisateur. Cette mécanique est laissée à votre discrétion, il faudra donc l’implémenter.

Dans le projet du SSO, créez un dossier Ciba dans lequel vous créerez une classe BackchannelAuthenticationUserValidator. Cette classe héritera de IBackchannelAuthenticationUserValidator.

public class BackchannelAuthenticationUserValidator : IBackchannelAuthenticationUserValidator  
{  
  private...

Application cliente

1. Application MVC

Créez une application cliente ASP.NET MVC basique :

images/15EI002.png

Dans le fichier Program.cs, ajoutez le nécessaire pour l’authentification via cookie :

using Microsoft.AspNetCore.Authentication.Cookies;  
  
var builder = WebApplication.CreateBuilder(args);  
  
builder.Services.AddControllersWithViews();  
  
builder.Services.AddAuthentication 
(CookieAuthenticationDefaults.AuthenticationScheme)  
    .AddCookie();  
  
builder.Services.AddHttpClient();  
  
var app = builder.Build();  
  
if (!app.Environment.IsDevelopment())  
{  
    app.UseExceptionHandler("/Home/Error");  
    app.UseHsts();  
}  
  
app.UseHttpsRedirection();  
app.UseStaticFiles();  
  
app.UseRouting();  
  
app.UseAuthentication();  
app.UseAuthorization();  
  
app.MapControllerRoute(  
    name: "default",  
    pattern: "{controller=Home}/{action=Index}/{id?}")  
    .RequireAuthorization();  
  
app.Run(); 

Notez le .RequireAuthorization() sur le mapping des routes de contrôleur. Le but est, comme à chaque fois, d’interdire totalement l’accès à l’application sans authentification.

2. AccountController

Par défaut, l’authentification via cookie redirige les utilisateurs non authentifiés vers /account/login. Cette convention étant tout à fait satisfaisante, nous allons nous reposer dessus.

Créez un AccountController dans le répertoire Controllers de votre application cliente. Celui-ci devra être accessible sans authentification, il faut donc faire un contournement de la règle générale.

a. Login

Créez une méthode Login() dans le contrôleur :

[AllowAnonymous]  
public class AccountController : Controller  
{  
  [HttpGet]  
  public async Task<IActionResult> Login()  
    => View();  
}...