Introduction

L'authentification des utilisateurs dans AppScho

L'authentification chez AppScho dévie légèrement des cas d'usage habituels qui peuvent être rencontrés sur le Web. Etant une application mobile native, nous ne disposons pas des mécanismes utilisés sur le Web afin d'authentifier les utilisateurs et de maintenir des sessions dans le temps.

Les mécanismes spécifiques présentés dans les sections suivantes sont des exemples métier classiques. Il nous est possible d'utiliser d'autres méthodes (une API, par exemple), tant que celles-ci respectent les prérequis ci-dessous.

Renouvellement de session

Notamment, à l'instar des méthodes utilisées habituellement par l'authentification SAML ou CAS, nous ne pouvons pas rediriger l'utilisateur vers l'Identity Provider (IDP) afin que celui-ci puisse renouveler la session à l'aide de cookies. SAML est par exemple inutilisable pour AppScho.

Certains protocole d'authentification ou d'autorisation modernes permettent le renouvellement de session transparent et sans état, afin notamment de permettre leur utilisation sur des applications natives, c'est le cas, par exemple, d'OAuth2 ou OpenID Connect. Pour les protocoles ne possédant pas de notion de rafraîchissement de session, une nouvelle session doit être recréée, et par conséquent, les identifiants de l'utilisateur doivent être stockés pour réutilisation.

Lorsque les identifiants de l'utilisateur doivent être stockées, ils le sont sur le terminal de l'utilisateur, jamais par AppScho ou un tiers.

Informations utilisateurs

Certains protocoles d'authentification incluent des éléments permettant de transmettre certaines informations sur l'utilisateur connecté à l'application client. Par exemple, CAS permet de configurer certains attributs qui seront renvoyés au service une fois l'utilisateur authentifié. De même, OAuth2 et OpenID Connect permettent la récupérer de ces données utilisateurs en fonction des scopes autorisés par l'utilisateur.

AppScho peut, lorsque le protocole le permet, d'utiliser ces informations dans à des fins cosmétiques (afficher le nom de l'utilisateur dans l'application) et fonctionnels (connaître la clé unique d'un utilisateur pour paramétriser les requêtes ultérieures).

Dans le cas où le protocole utilisé par votre établissement ne permettrait pas la récupération directe de ces informations, ou de toutes les informations nécessaires, d'autres vecteurs devront être utilisés pour l'obtention de ces données, par exemple, l'utilisation d'une API mise à disposition par l'établissement ou l'interconnexion avec l'ERP.