Authentification Shiny : ajouter une connexion sécurisée à votre application

Q: Comment ajouter une connexion à une application Shiny ?

Pour une application autonome, utilisez le package shinymanager : enveloppez votre UI avec secure_app(ui) et ajoutez secure_server(check_credentials = check_credentials(credentials)) dans votre serveur. Cela injecte une page de connexion devant l’application en quelques lignes. Pour une équipe, hébergez plutôt l’application derrière une plateforme (ShinyProxy, Posit Connect, ou un forfait payant shinyapps.io) et activez son authentification intégrée.

Q: shinymanager est-il sécurisé — comment stocke-t-il les mots de passe ?

shinymanager stocke les identifiants dans une base de données SQLite chiffrée (chiffrée avec openssl) et hache chaque mot de passe avec le package scrypt, de sorte que les mots de passe ne sont jamais conservés en clair (documentation). Vous créez la base de données avec create_db(..., passphrase = ...) et conservez cette phrase secrète dans une variable d’environnement, pas dans votre code. C’est un choix solide pour une application autonome ; pour le SSO et la MFA à l’échelle de l’organisation, déléguez plutôt à une plateforme et à un fournisseur d’identité.

Q: Comment hacher un mot de passe en R ?

Utilisez sodium::password_store("your_password") pour produire un hachage scrypt salé, et sodium::password_verify(stored_hash, candidate) pour vérifier une tentative de connexion (documentation de sodium). Stockez le hachage, jamais le mot de passe. Dans une application Shiny, shinymanager le fait déjà pour vous, vous appelez donc rarement sodium directement. N’utilisez jamais MD5 ni SHA-1 pour les mots de passe — ils ne sont pas salés et sont trop rapides pour être sûrs.

Q: Authentification shinymanager ou ShinyProxy — laquelle utiliser ?

Utilisez shinymanager quand vous avez une seule application autonome et une courte liste d’utilisateurs que vous gérez vous-même — elle vit dans votre application et ne nécessite aucune infrastructure supplémentaire. Utilisez l’authentification ShinyProxy (ou Posit Connect) quand vous hébergez des applications pour une équipe, exploitez déjà un annuaire ou un SSO, ou avez besoin de LDAP/OpenID/SAML et de MFA — la plateforme authentifie et votre application ne porte aucun code de connexion. Petit et autonome → shinymanager ; équipe et entreprise → native de la plateforme.

Protégez votre application avec une vraie connexion — déléguez à shinymanager ou à votre fournisseur d’identité, ne bricolez jamais la cryptographie.

Programming

Shiny

Ajoutez une authentification à une application Shiny comme il faut. Déléguez à shinymanager pour une application autonome (une page de connexion plus des identifiants hachés avec scrypt en quelques lignes) et à l’authentification native de la plateforme (ShinyProxy LDAP/OpenID/SAML, Posit Connect, shinyapps.io) pour une équipe. Hachez les identifiants avec scrypt, ajoutez des rôles, et déléguez l’authentification unique et l’authentification multifacteur à votre fournisseur d’identité — n’écrivez jamais vous-même de code de session, de jeton ou de cryptographie.

Date de publication

16 juillet 2026

Modifié

16 juillet 2026

Points clés

Ne bricolez jamais l’authentification vous-même. Les pages de connexion, les jetons de session, le hachage des mots de passe et l’authentification unique sont des problèmes résolus, aux modes de défaillance subtils. Déléguez à un outil éprouvé — vous le configurez, vous ne le reconstruisez pas.
Application autonome → shinymanager. Enveloppez votre UI dans secure_app() et protégez le serveur avec secure_server(), et votre application obtient une page de connexion plus des identifiants hachés en quelques lignes.
Équipe / organisation → authentification native de la plateforme. ShinyProxy, Posit Connect et shinyapps.io gèrent la connexion à votre place — y compris l’authentification unique LDAP (Lightweight Directory Access Protocol), OpenID Connect et SAML — sans aucun code d’authentification dans votre application.
Hachez les mots de passe, toujours. shinymanager stocke les identifiants sous forme de hachages scrypt (via le package scrypt), jamais en clair. Si vous hachez un jour un mot de passe vous-même, utilisez une primitive auditée comme sodium::password_store() — pas un schéma maison.
The runtime is the judge. Quand une page de connexion apparaît devant votre application et que seuls les bons identifiants passent, vous avez prouvé que la protection fonctionne.

Introduction

Votre application est en ligne sur une URL publique — vous l’avez déployée sur shinyapps.io ou conteneurisée — et quiconque a le lien peut l’ouvrir. C’est très bien pour une démonstration publique, mais pas quand l’application affiche des chiffres internes, des données de patients ou le tableau de bord d’un client. Il vous faut une connexion : seules les personnes autorisées entrent, et certaines en voient plus que d’autres.

Voici la seule règle qui compte, d’emblée : ne construisez pas la connexion vous-même. L’authentification a une douzaine de façons non évidentes d’échouer — comparaison à temps constant, hachage salé, fixation de session, expiration de jeton, verrouillage anti-force brute — et se tromper sur une seule expédie une faille. Chacune est déjà résolue par des outils testés, audités et maintenus. Votre travail consiste à déléguer à l’une de ces deux voies :

Voie A — une application autonome. Ajoutez une connexion avec le package shinymanager. Il injecte une page de connexion devant votre application et vérifie les identifiants contre un magasin haché — quelques lignes, aucun code de cryptographie.
Voie B — une équipe ou une organisation. Placez l’application derrière une authentification native de la plateforme — ShinyProxy, Posit Connect ou shinyapps.io. Quand votre entreprise dispose déjà d’un système d’identité (un annuaire ou une authentification unique), la plateforme lui délègue : le fournisseur d’identité gère la connexion, la politique de mots de passe et les invites multifacteur, et votre application ne voit jamais de mot de passe.

Le reste de cette leçon parcourt les deux voies, montre comment stocker les mots de passe correctement, ajoute des rôles, et couvre l’authentification unique et l’authentification multifacteur — toujours en déléguant, jamais en bricolant soi-même.

Prérequis

Il vous faut une application déployée et fonctionnelle à protéger — si vous n’en avez pas encore, déployez sur shinyapps.io ou conteneurisez votre application d’abord. Pour la voie A, installez le package avec install.packages("shinymanager"). Pour la voie B, il vous faut la plateforme (ShinyProxy, Posit Connect ou un forfait payant shinyapps.io) et, idéalement, les détails du fournisseur d’identité de votre organisation.

Copiez n’importe quel bloc et exécutez-le en local

Le code d’application de cette page n’est pas exécuté ici — une application Shiny a besoin d’une session R active et d’un navigateur, ce qu’une page web statique ne peut pas héberger. Copiez n’importe quel bloc dans un app.R et exécutez-le en local avec shiny::runApp(). Le vrai test, c’est ce que vous voyez : une page de connexion apparaît devant votre application, les bons identifiants vous laissent entrer, les mauvais non. C’est la preuve que la protection fonctionne — the runtime is the judge.

Voie A — ajouter une connexion avec shinymanager

Pour une application autonome, shinymanager est la réponse correcte la plus rapide. Vous enveloppez votre UI existante dans secure_app() et ajoutez un appel à l’intérieur de votre serveur. Voici une application complète et protégée :

library(shiny)
library(shinymanager)

# For a first demo, an inline credentials data frame.
# shinymanager hashes these passwords for you — you never store plaintext.
credentials <- data.frame(
  user     = c("alice", "bob"),
  password = c("alice_pw", "bob_pw"),
  admin    = c(TRUE, FALSE),          # a role flag we'll use below
  stringsAsFactors = FALSE
)

ui <- fluidPage(
  titlePanel("Protected dashboard"),
  plotOutput("distPlot")
)
ui <- secure_app(ui)                   # wrap the UI: a login page is injected in front

server <- function(input, output, session) {
  res_auth <- secure_server(
    check_credentials = check_credentials(credentials)
  )
  output$distPlot <- renderPlot(
    hist(faithful$waiting, col = "#3a86d4", border = "white")
  )
}

shinyApp(ui, server)

Lisez les trois éléments en jeu :

secure_app(ui) enveloppe toute votre UI. Au lieu d’afficher le tableau de bord immédiatement, shinymanager affiche une page de connexion ; ce n’est qu’après une connexion réussie que votre véritable UI apparaît. Ses options vous permettent de personnaliser et de localiser la page et d’activer un panneau d’administration intégré — secure_app(ui, enable_admin = TRUE, theme = ..., language = "en").
secure_server(check_credentials = ...) protège le serveur. Rien dans votre fonction server ne s’exécute pour un visiteur tant qu’il ne s’est pas authentifié. Il accepte aussi timeout (déconnexion automatique après inactivité) et max_users.
check_credentials(credentials) est le validateur. Il compare l’identifiant et le mot de passe soumis à votre magasin et renvoie l’enregistrement de l’utilisateur correspondant — y compris cet indicateur admin — que secure_server() restitue sous la forme de res_auth.

Exécutez ceci en local et vous obtiendrez une page de connexion devant l’histogramme. alice et bob entrent avec leurs mots de passe ; toute autre personne est refusée. Ce data frame en ligne convient pour une démonstration, mais ce n’est pas ainsi qu’on expédie en production — la section suivante corrige le stockage.

Bien gérer les mots de passe — hachez-les, gardez le secret hors du code

Un data frame credentials en ligne signifie que les mots de passe résident dans votre code source. Pour la production, shinymanager stocke les identifiants dans une base de données SQLite chiffrée (chiffrée avec openssl), avec des mots de passe hachés à l’aide du package scrypt, jamais en clair (documentation du stockage sécurisé de shinymanager). Vous construisez la base de données une seule fois avec create_db() :

library(shinymanager)

credentials <- data.frame(
  user     = c("alice", "bob"),
  password = c("alice_pw", "bob_pw"),
  admin    = c(TRUE, FALSE),
  stringsAsFactors = FALSE
)

# Create the encrypted credentials database (run this once, not inside the app)
create_db(
  credentials_data = credentials,
  sqlite_path      = "path/to/database.sqlite",
  passphrase       = "a-strong-passphrase"   # encrypts the DB — never hard-code this
)

Pointez ensuite l’application vers cette base de données plutôt que vers le data frame, et lisez la phrase secrète depuis une variable d’environnement pour qu’elle ne touche jamais votre code source ni votre historique git :

server <- function(input, output, session) {
  res_auth <- secure_server(
    check_credentials = check_credentials(
      "path/to/database.sqlite",
      passphrase = Sys.getenv("DB_PASSPHRASE")   # set in the environment, not in code
    )
  )
  # ... your outputs ...
}

Définissez DB_PASSPHRASE dans l’environnement où l’application s’exécute (un fichier .Renviron, un secret de conteneur, ou le gestionnaire de secrets de votre plateforme) — les leçons shinyapps.io et Docker montrent toutes deux où.

Si vous devez un jour hacher un mot de passe en dehors de shinymanager, utilisez sodium directement — sodium::password_store("secret") renvoie un hachage scrypt, et sodium::password_verify(hash, "secret") vérifie un candidat par rapport à ce hachage, en renvoyant TRUE ou FALSE (référence de sodium). Ce que vous ne devez jamais faire, c’est inventer votre propre hachage, stocker les mots de passe en clair, ou recourir à un simple condensé comme MD5 ou SHA-1 — ceux-ci ne sont pas salés et sont rapides, ce qui est exactement l’inverse de ce qu’il faut pour des mots de passe.

Rôles et contrôle d’accès (RBAC)

La plupart des applications ont besoin de plus que « dedans ou dehors » — un analyste voit le tableau de bord, un administrateur voit aussi le panneau de gestion des utilisateurs. C’est le RBAC (role-based access control, contrôle d’accès basé sur les rôles) : ce qu’un utilisateur peut faire dépend de son rôle.

shinymanager vous offre une colonne pour cela. L’indicateur admin (et toute colonne supplémentaire que vous ajoutez, comme group) accompagne l’utilisateur, et secure_server() le renvoie dans res_auth. Lisez-le dans le serveur pour afficher ou masquer l’UI selon le rôle :

server <- function(input, output, session) {
  res_auth <- secure_server(
    check_credentials = check_credentials(credentials)
  )

  # res_auth$admin is TRUE / FALSE for the logged-in user
  output$admin_panel <- renderUI({
    if (isTRUE(as.logical(res_auth$admin))) {
      tagList(h3("Admin panel"), actionButton("manage_users", "Manage users"))
    }
  })
}

Comme res_auth est réactif, l’UI reflète automatiquement le rôle de l’utilisateur courant — il n’y a pas de base de données de permissions distincte à raccorder pour les cas simples. Pour un gestionnaire complet d’utilisateurs et de rôles, secure_app(ui, enable_admin = TRUE) ajoute un écran d’administration intégré permettant de créer des utilisateurs et de définir leurs indicateurs. Pour une équipe suivant la voie B, les rôles proviennent généralement du fournisseur d’identité (ses groupes), que la plateforme met en correspondance avec l’accès aux applications — aucune table de rôles dans votre application.

Voie B — authentification native de la plateforme pour une équipe

Quand plus d’une poignée de personnes utilisent l’application, ou que votre organisation dispose déjà d’un système de connexion, ne gérez pas du tout les identifiants dans votre application. Placez l’application derrière une plateforme qui s’authentifie à votre place.

flowchart LR
    U[Navigateur de l'utilisateur] --> P[Plateforme d'hébergement]
    P --> IDP[Fournisseur d'identité : LDAP / OIDC / SAML]
    IDP -->|identité vérifiée + groupes| P
    P --> A[Votre application Shiny]

L’utilisateur se connecte contre votre système d’identité existant ; la plateforme relit qui il est et à quels groupes il appartient, et ce n’est qu’ensuite qu’elle charge votre application. Trois plateformes courantes :

ShinyProxy — l’option open-source et auto-hébergée. Elle intègre l’authentification d’entreprise : définissez proxy.authentication sur ldap, openid ou saml dans application.yml avec les paramètres de connexion proxy.<mode>.* correspondants, et elle gère le protocole (documentation de configuration de ShinyProxy). La leçon ShinyProxy couvre cette configuration de bout en bout.
Posit Connect — la plateforme commerciale. L’authentification unique contre des fournisseurs LDAP, SAML et OIDC est intégrée et configurée par un administrateur, sans aucun code dans votre application (documentation d’authentification de Posit Connect).
shinyapps.io — le service d’hébergement géré. Ses forfaits payants (Standard et supérieurs) ajoutent une bascule de connexion qui restreint votre application aux comptes autorisés — une case à cocher, pas du code (guide d’authentification de shinyapps.io).

Le principe des trois est le même : vous déléguez. Choisissez la plateforme que votre organisation utilise et laissez-la gérer la connexion.

Authentification unique et authentification multifacteur

Deux fonctionnalités que vous ne devriez jamais construire à la main, car la délégation vous les offre gratuitement :

Le SSO (single sign-on, authentification unique) permet à un utilisateur de se connecter une seule fois avec son compte d’entreprise et d’atteindre toutes les applications internes — sans mot de passe distinct par application. Vous l’obtenez en configurant OIDC (OpenID Connect — un standard moderne à base de jetons) ou SAML (Security Assertion Markup Language — le standard XML derrière une grande partie du SSO d’entreprise) sur votre plateforme, en la pointant vers votre IdP (fournisseur d’identité — le service qui détient les comptes et vérifie les connexions, comme Keycloak, Okta, Microsoft Entra ID ou Google). L’IdP vérifie l’utilisateur et indique à la plateforme qui il est.
La MFA (multi-factor authentication, authentification multifacteur) — une seconde preuve au-delà du mot de passe, comme un code TOTP (time-based one-time password, mot de passe à usage unique basé sur le temps) issu d’une application d’authentification. Vous n’implémentez pas la MFA dans votre application Shiny. Elle est imposée par le fournisseur d’identité : quand la plateforme délègue la connexion à l’IdP via OIDC ou SAML, la politique de MFA de l’IdP s’applique automatiquement, et l’utilisateur la complète avant même que votre application ne se charge.

La règle pratique pour les deux : choisissez OIDC ou SAML sur votre plateforme, et l’IdP prend en charge la politique de mots de passe, le SSO et la MFA. Écrire soi-même un flux OAuth, un vérificateur TOTP ou un schéma de session ne fait que réimplémenter — mal — ce que votre IdP fait déjà correctement.

À ne pas faire

L’ancienne approche bricolée maison de l’authentification Shiny est un catalogue d’anti-patrons. Évitez-les tous :

Mots de passe en clair. Stocker (ou journaliser) un mot de passe tel quel signifie qu’une seule fuite expose tout le monde. Hachez avec shinymanager (ou sodium si vous le faites vous-même), toujours.
Jetons de session ou JWT maison. Émettre, signer et faire expirer vos propres jetons invite à la fixation de session et aux bugs de rejeu. Laissez shinymanager ou la plateforme gérer les sessions.
Cryptographie maison. N’inventez jamais de schéma de chiffrement ou de hachage, et n’utilisez jamais un condensé rapide et non salé (MD5/SHA-1) pour les mots de passe. Utilisez des primitives auditées (scrypt/sodium).
« Une URL secrète, c’est de la sécurité. » Un lien impossible à deviner n’est pas un contrôle d’accès — il fuit par l’historique, les référents et les favoris partagés. Exigez une vraie connexion.
Une simple vérification if (password == input$pw). Une comparaison naïve n’est pas à temps constant et n’a aucun verrouillage ; c’est exactement ce que les outils existent pour remplacer.

Notez que l’authentification n’est que la moitié « qui entre » du durcissement. L’autre moitié — la validation des entrées, la protection contre les injections, la gestion des secrets et la définition des en-têtes de sécurité HTTPS — relève de la leçon sécurité compagnon de cette série ; mettez les deux en place pour une application de production.

Quelle approche pour quel besoin

Faites correspondre l’outil à la situation :

	shinymanager (voie A)	Native de la plateforme (voie B)
Idéal pour	Une application autonome, quelques utilisateurs connus	Une équipe, une organisation, le SSO d’entreprise
Où résident les utilisateurs	Un fichier que vous gérez (SQLite chiffré)	Votre annuaire / fournisseur d’identité
Mise en place	Quelques lignes dans votre application	Configuration de la plateforme, aucun code applicatif
SSO / MFA	Non intégrés	Oui — délégués à l’IdP
Rôles	`admin` / colonnes personnalisées dans `res_auth`	Groupes issus du fournisseur d’identité
Vous administrez	Juste votre application	ShinyProxy / Connect / shinyapps.io

Optez pour shinymanager quand vous possédez une seule application et gérez vous-même une courte liste d’utilisateurs. Optez pour l’authentification native de la plateforme dès que vous avez une équipe, un système de connexion existant, ou un besoin de SSO et de MFA — alors c’est la plateforme, pas votre code, qui porte la sécurité.

Problèmes fréquents

La connexion fonctionne en local mais pas une fois déployée. L’application authentifie sur votre machine mais rejette tout le monde (ou renvoie une erreur) en production. Presque toujours, la variable d’environnement DB_PASSPHRASE n’est pas définie dans l’environnement déployé, ou le chemin SQLite n’y existe pas. Définissez la phrase secrète dans les paramètres de secrets/d’environnement de votre plateforme et livrez la base de données d’identifiants (ou recréez-la) aux côtés de l’application. Servez aussi l’application via HTTPS — une connexion envoyée en HTTP simple est exposée pendant le transit.

Les utilisateurs ne peuvent pas se connecter même avec le bon mot de passe. check_credentials() pointe vers un mauvais chemin de base de données ou reçoit une mauvaise phrase secrète, il ne peut donc pas lire le magasin. Vérifiez que sqlite_path correspond au fichier déployé et que Sys.getenv("DB_PASSPHRASE") renvoie la même phrase secrète que celle utilisée dans create_db() (une chaîne vide signifie que la variable n’est pas définie).

L’UI basée sur les rôles ne se met pas à jour par utilisateur. Vous avez codé en dur le panneau d’administration ou lu une valeur fixe au lieu de res_auth. Pilotez l’UI dépendante du rôle à partir de res_auth$admin (ou de votre colonne de groupe) dans un renderUI()/observe() réactif, pour qu’elle reflète l’utilisateur connecté. Rappelez-vous que secure_server() renvoie res_auth — lisez-le, ne redérivez pas le rôle.

Questions fréquentes

Comment ajouter une connexion à une application Shiny ?

Pour une application autonome, utilisez le package shinymanager : enveloppez votre UI avec secure_app(ui) et ajoutez secure_server(check_credentials = check_credentials(credentials)) dans votre serveur. Cela injecte une page de connexion devant l’application en quelques lignes. Pour une équipe, hébergez plutôt l’application derrière une plateforme (ShinyProxy, Posit Connect, ou un forfait payant shinyapps.io) et activez son authentification intégrée.

shinymanager est-il sécurisé — comment stocke-t-il les mots de passe ?

shinymanager stocke les identifiants dans une base de données SQLite chiffrée (chiffrée avec openssl) et hache chaque mot de passe avec le package scrypt, de sorte que les mots de passe ne sont jamais conservés en clair (documentation). Vous créez la base de données avec create_db(..., passphrase = ...) et conservez cette phrase secrète dans une variable d’environnement, pas dans votre code. C’est un choix solide pour une application autonome ; pour le SSO et la MFA à l’échelle de l’organisation, déléguez plutôt à une plateforme et à un fournisseur d’identité.

Comment ajouter l’authentification unique (SSO) à une application Shiny ?

Vous ne construisez pas le SSO dans l’application — vous déléguez à une plateforme d’hébergement qui parle le protocole de votre fournisseur d’identité. Placez l’application derrière ShinyProxy (authentication: openid ou saml), Posit Connect, ou une plateforme gérée, et configurez OpenID Connect ou SAML contre votre fournisseur (Keycloak, Okta, Entra ID, Google). Le fournisseur vérifie l’utilisateur et la plateforme charge l’application — aucun code d’authentification dans Shiny.

Comment hacher un mot de passe en R ?

Utilisez sodium::password_store("your_password") pour produire un hachage scrypt salé, et sodium::password_verify(stored_hash, candidate) pour vérifier une tentative de connexion (documentation de sodium). Stockez le hachage, jamais le mot de passe. Dans une application Shiny, shinymanager le fait déjà pour vous, vous appelez donc rarement sodium directement. N’utilisez jamais MD5 ni SHA-1 pour les mots de passe — ils ne sont pas salés et sont trop rapides pour être sûrs.

Authentification shinymanager ou ShinyProxy — laquelle utiliser ?

Utilisez shinymanager quand vous avez une seule application autonome et une courte liste d’utilisateurs que vous gérez vous-même — elle vit dans votre application et ne nécessite aucune infrastructure supplémentaire. Utilisez l’authentification ShinyProxy (ou Posit Connect) quand vous hébergez des applications pour une équipe, exploitez déjà un annuaire ou un SSO, ou avez besoin de LDAP/OpenID/SAML et de MFA — la plateforme authentifie et votre application ne porte aucun code de connexion. Petit et autonome → shinymanager ; équipe et entreprise → native de la plateforme.

Testez vos connaissances

À vous de jouer : protéger une application avec shinymanager

Prenez cette application ouverte et placez une connexion devant elle, en autorisant un seul utilisateur dana avec le mot de passe secret. Quelles sont les deux modifications que vous apportez au code ?

library(shiny)

ui <- fluidPage(
  titlePanel("Protected dashboard"),
  plotOutput("distPlot")
)

server <- function(input, output, session) {
  output$distPlot <- renderPlot(
    hist(faithful$waiting, col = "#3a86d4", border = "white")
  )
}

shinyApp(ui, server)

Indice

Chargez shinymanager, construisez un data frame credentials d’une seule ligne, puis (1) enveloppez l’UI avec secure_app() et (2) ajoutez un appel secure_server(check_credentials = check_credentials(credentials)) comme première ligne de votre serveur.

Solution

library(shiny)
library(shinymanager)

credentials <- data.frame(
  user     = "dana",
  password = "secret",
  stringsAsFactors = FALSE
)

ui <- fluidPage(
  titlePanel("Protected dashboard"),
  plotOutput("distPlot")
)
ui <- secure_app(ui)                       # change 1: wrap the UI with a login page

server <- function(input, output, session) {
  res_auth <- secure_server(               # change 2: guard the server
    check_credentials = check_credentials(credentials)
  )
  output$distPlot <- renderPlot(
    hist(faithful$waiting, col = "#3a86d4", border = "white")
  )
}

shinyApp(ui, server)

Les deux modifications sont ui <- secure_app(ui) (injecter la page de connexion) et l’appel secure_server(check_credentials = ...) (valider la connexion et protéger le serveur). Exécutez-la et seul dana avec secret accède à l’histogramme. Pour la production, remplacez le data frame en ligne par une base de données chiffrée issue de create_db() et lisez la phrase secrète depuis Sys.getenv("DB_PASSPHRASE") — ne conservez jamais le mot de passe dans le code source.

Vérification rapide

Votre entreprise utilise Microsoft Entra ID et veut que les employés se connectent à un nouveau tableau de bord Shiny avec leurs comptes d’entreprise existants, y compris l’invite multifacteur de l’entreprise. Quelle est la bonne approche ?

A. Écrire un formulaire de connexion dans l’application et vérifier les mots de passe contre Entra ID à la main.
B. Héberger l’application derrière une plateforme (ShinyProxy ou Posit Connect) configurée avec OpenID Connect / SAML contre Entra ID, et laisser le fournisseur d’identité gérer la connexion et la MFA.
C. Stocker le mot de passe d’entreprise de chacun dans une base de données shinymanager.
D. Placer l’application à une URL secrète et la partager uniquement avec les employés.

Afficher la réponse

B. Le SSO d’entreprise, c’est exactement à cela que sert l’authentification native de la plateforme : configurez OpenID Connect ou SAML contre Entra ID, et le fournisseur d’identité vérifie l’utilisateur et impose sa propre politique de MFA avant que l’application ne se charge — aucun code d’authentification dans votre application. A réimplémente (mal) ce que l’IdP fait déjà et nécessiterait les mots de passe des utilisateurs ; C duplique et gère mal des identifiants d’entreprise que vous ne devriez jamais stocker ; D n’est pas du tout un contrôle d’accès. Déléguez au fournisseur d’identité.

Conclusion

Placer une connexion devant une application Shiny est un problème de délégation, pas un projet de cryptographie. Pour une application autonome, shinymanager vous donne une page de connexion et des identifiants chiffrés et hachés avec scrypt en quelques lignes : enveloppez l’UI dans secure_app(), protégez le serveur avec secure_server(), stockez les mots de passe avec create_db(), et conservez la phrase secrète dans une variable d’environnement. Pour une équipe, hébergez l’application derrière ShinyProxy, Posit Connect ou shinyapps.io et laissez la plateforme s’authentifier contre votre annuaire ou votre fournisseur d’identité — ce qui apporte aussi le SSO et la MFA gratuitement. Quelle que soit la voie choisie, le principe tient : configurez un outil éprouvé, n’écrivez jamais vous-même de code de session, de jeton ou de cryptographie. Quand une page de connexion se dresse entre Internet et votre application et que seules les bonnes personnes passent, le runtime a prouvé que la protection fonctionne.

Leçons connexes

Déployez d’abord, protégez ensuite : conteneuriser votre application ou déployer sur shinyapps.io vous donne l’application en fonctionnement que cette leçon sécurise, et ShinyProxy est la façon auto-hébergée d’ajouter une connexion d’entreprise LDAP/OpenID/SAML pour toute une équipe. Nouveau sur Shiny ? Construire votre première application Shiny, c’est là que l’application commence.
Aller plus loin : Applications web Shiny — tout le cursus Shiny. · Science computationnelle et IA — le pilier.

Cette page vous a-t-elle été utile ?

Prouvez que vous savez le faire. Maîtrisez toute la série Shiny en production — suivez votre parcours, construisez des projets et obtenez un certificat.

Commencer gratuitement →

Passez à Pro — Prova illimité sur vos propres données et un certificat vérifiable qui atteste la compétence.

dès 15 $/mois facturé annuellement

Passer à Pro →

✓ Vous êtes Pro — continuez. The runtime is the judge.

Réutilisation

CC BY-NC-SA 4.0

Citation

BibTeX

@online{2026,
  author = {},
  title = {Authentification Shiny : ajouter une connexion sécurisée à
    votre application},
  date = {2026-07-16},
  url = {https://www.datanovia.com/learn/programming/shiny/production/authentication},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“Authentification Shiny : ajouter une connexion sécurisée à votre application.” 2026. July 16. https://www.datanovia.com/learn/programming/shiny/production/authentication.