Salut tout le monde, je suis Mod Shadow et je suis l'architecte de notre plateforme d'édition ! Vous aimeriez en savoir plus sur les aspects plus techniques du Jagex Launcher ? Eh bien, aujourd'hui, je vais vous révéler tous les secrets de son évolution dans le temps pour en arriver jusqu'à sa forme actuelle !
Mais je vous préviens, cet article contient des détails hautement techniques, alors accrochez-vous ! Au fil de ma présentation, je vous fournirai également des liens vers d'autres sources pour que vous puissiez approfondir le sujet si ça vous intéresse.
C'était en l'an 2016...
... et dans le studio, l'idée d'un launcher, capable d'unifier tous nos jeux sous la même bannière, était sur toutes les lèvres. Nous avions même créé un prototype démontrant comment un joueur pouvait installer et lancer Old School et RuneScape depuis une même application centrale sur son humble bureau Windows.
Avance rapide vers le milieu de l'année 2017 : une petite équipe avait été constituée pour commencer à travailler sur le launcher. Nous avions des idées ambitieuses pour que les joueurs prolongent leurs sessions de plusieurs jours, voire de plusieurs semaines, au lieu de quelques heures, ce qui était alors la norme. Ainsi, les gens pourraient accéder rapidement à leurs jeux préférés sans avoir à retaper leur nom d'utilisation et leur mot de passe. Ça vous rappelle quelque chose ?
RS Mobile
Cette même année, Jagex a annoncé qu'Old School et RuneScape seraient désormais disponibles sur mobile. Nous avons donc mis le launcher de côté pour nous concentrer sur ce projet. Ceci dit, ce dernier objectif nous a donné de nouvelles idées pour le launcher, car les appareils mobiles exigeaient également des sessions plus longues. Aujourd'hui encore, il est possible de lancer les applis iOS et Android et d'appuyer simplement sur « Jouer » à condition de s'être connecté une fois par le passé. Ce mécanisme est en quelque sorte le premier exemple de ce que nous vous proposons à présent avec le launcher, car ses concepts de base (agrémentés d'un peu de magie Jagex) sont fondamentalement les mêmes.
Des débuts à tâtons
Vous avez peut-être entendu parler du protocole OAuth2 – il existe depuis un bon moment. Même si ça ne vous dit rien, vous l'utilisez sûrement tous les jours sans même le savoir ! À chaque fois que vous vous connectez à quelque chose avec votre compte Google, Facebook, Twitter ou même Twitch, vous y recourez. Jagex n'en est pas l'inventeur, il a été développé au fil de nombreuses années par des professionnels de la cybersécurité afin de vous fournir une méthode d'autorisation en béton pour utiliser des logiciels. C'est un système fiable et utilisé par des milliers d'éditeurs de logiciels pour protéger leurs comptes de la façon la plus sûre qui soit.
Cependant, RuneScape existe également depuis belle lurette, et le jeu possédait déjà sa propre méthode de connexion pour ses utilisateurs, à laquelle ceux-ci étaient habitués. Nous avons donc commencé à introduire ce nouveau mécanisme avec une grande précaution. Le protocole OAuth2 comprend deux types de jetons : un jeton d'accès, utilisé pour autoriser les appels réseau, et un jeton d'actualisation, servant à obtenir un nouveau jeton d'accès après expiration du précédent. Ce sont ces jetons qui nous permettent de vous reconnecter au jeu, même si vous n'avez pas joué depuis plusieurs jours sur mobile. À l'époque, afin de préserver notre expérience utilisateur, nous utilisions la spécification d'extension du protocole OAuth2 que nous avions reliée à nos procédés de de connexion afin de générer ces jetons. C'était notre premier pas vers une nouvelle méthode de connexion. Nous avons introduit cette fonctionnalité dans le cadre de la bêta mobile, puis du lancement d'Old School sur mobile en 2018.
Évolution
À ce stade, nous commencions à peine à utiliser les mécanismes du protocole OAuth2 pour permettre aux utilisateurs de se connecter au jeu. Nous savions que nous voulions passer aux flux OAuth2 classiques pour ne plus avoir à utiliser notre extension. L'utilisation de l'un des flux standards, par exemple authorization_code, présentait plusieurs avantages :
- Nous pourrions faire appliquer un principe de moindre privilège : un seul emplacement serait responsable de votre nom d'utilisateur et votre mot de passe, et vous n'auriez pas à le retaper à différents endroits (ex : site Web, client du jeu OSRS et client du jeu RS). De cette façon, vos données de connexion sensibles ne seraient partagées avec aucun autre système.
- Nous pourrions unifier le processus de connexion et offrir ainsi la même expérience utilisateur, que vous vous connectiez à Old School ou à RuneScape. Ceci nous permettrait également de centraliser les différentes méthodes de connexion (via Google, Apple et Facebook) sans avoir à effectuer une volumineuse mise à jour du client de jeu, voire pas de mise à jour du tout !
- Nous pourrions mettre en œuvre des contrôles de sécurité stricts et utiliser des logiciels de pointe pour protéger plus efficacement les joueurs des utilisateurs malveillants, car la connexion n'aurait lieu qu'à un seul endroit, et parce que nous nous servirions du protocole HTTP au lieu du protocole personnalisé utilisé par nos clients de jeu.
- Nous ouvririons la voie à l'intégration d'autres systèmes développés par nous-mêmes, avec des fonctionnalités de connexion plus rapides que les méthodes personnalisées que nous utilisions avant.
Cependant, ce système représentait un défi technique, mais aussi un défi au niveau de l'expérience utilisateur. Le protocole OAuth2 a été conçu pour être utilisé par un navigateur Web, soit un système qui prend en compte HTML, CSS, JavaScript, qui stocke les cookies et gère les réponses HTTP. Or un client de jeu n'effectue pas ces choses-là directement.
Et comme le client mobile était déjà capable de gérer les jetons OAuth2, nous avons à nouveau décidé de commencer par là.
Connexion au navigateur sur mobile
Nous nous sommes d'abord concentrés sur la version mobile, car nous avions déjà fait de gros progrès avec l'utilisation des jetons OAuth2 sur cette plateforme. Il nous semblait donc logique d'améliorer le flux ici avant d'essayer de le recréer ailleurs. Les systèmes Android et iOS supportent bien ce genre de flux et proposent des fonctionnalités autorisant le protocole OAuth2 via des fenêtres de navigation spécialisées (respectivement Trusted Web Activity et ASWebAuthenticationSession) qui peuvent être lancées à partir d'applis mobiles.
Nous possédions déjà une expérience de connexion connue des utilisateurs sur navigateur, surnommée « flux de connexion Web ». Les gens utilisaient cette méthode depuis des années pour se connecter, gérer leurs comptes, publier sur les forums ou s'inscrire. Nous voulions donc réutiliser le plus d'éléments possibles. Nous avons passé beaucoup de temps avec les équipes de RuneScape et Old School pour nous assurer d'utiliser les bons contrôles de sécurité sur les fenêtres de navigation spécialisées susmentionnées. Nous avions pour objectif de créer un mécanisme efficace
pour permettre aux utilisateurs de se connecter en utilisant un même site Web de confiance, pour obtenir un accès et des jetons d'actualisation OAuth2 via un flux authorization_code OAuth2 standardisé, et pour se connecter au jeu sur mobile.
En décembre 2020, les utilisateurs qui se connectaient sur mobile passaient pour la toute première fois par ce nouveau flux – supporté par les mêmes protections que celles de nos connexions sur site Web ! Les captchas, les WAF, la limitation de débit et toutes les autres protections standardisées, uniquement disponibles grâce à un navigateur et des appels réseau HTTP, protégeaient dès lors les connexions au jeu mobile.
Et ce n'est pas tout !
Nous avions bien progressé avec Old School sur mobile : nous pouvions désormais modifier et ajouter des protections supplémentaires à la connexion, nous avions les sacro-saintes données de connexion sauvegardées, ainsi que tous les avantages mentionnés plus haut. Quand nous avons lancé RuneScape sur mobile en 2021, nous n'avons donc eu aucun mal à y intégrer le flux OAuth2. Mais comment allions-nous obtenir les mêmes avantages sur ordinateur ?
Contrairement à Android et iOS, Windows n'a pas de fenêtre de navigation spécialisée pouvant être utilisée de façon aussi fluide. L'utilisateur peut avoir plusieurs navigateurs qui ne supportent pas directement le système d'exploitation. Nous avons donc expérimenté avec le navigateur par défaut, en utilisant une méthode similaire aux connexions Apple et Google sur ordinateur.
Le principe était simple :
- Cliquez deux fois sur l'icône du bureau.
- Lancez le client de jeu.
- Cliquez sur « Login » (Connexion).
- Ouvrez le navigateur.
- Vérifiez votre identité.
- Vous êtes automatiquement redirigé vers le client de jeu.
- Entrez dans le jeu avec l'accès OAuth2 et les jetons d'actualisation.
Mais en pratique, l'expérience laissait à désirer. Voilà ce qui se passait réellement :
- Cliquez deux fois sur l'icône du bureau.
- Lancez le client de jeu.
- Cliquez sur « Login » (Connexion).
- Ouvrez le navigateur.
- Priez pour que le navigateur réagisse.
- Vérifiez votre identité.
- Recevez un message « Connexion réussie ! »
- Retournez dans le client manuellement.
- Attendez la fin du processus de connexion.
- Obtenez l'accès OAuth2 et les jetons d'actualisation grâce à l'ancienne méthode.
- Entrez dans le jeu.
Nous avons alors essayé de supprimer certaines étapes. Pourquoi ne pas commencer par lancer le navigateur avant le client de jeu ? Et plutôt que d'utiliser les mécanismes de connexion d'Apple et de Google, pourquoi ne pas essayer de lancer le client avec des mécanismes de gestion de protocoles ? Voyons le résultat obtenu :
- Cliquez deux fois sur l'icône du bureau.
- Ouvrez le navigateur.
- Vérifiez votre identité.
- Recevez le message « Connexion réussie ».
- Recevez un message « Voulez-vous vraiment ouvrir ce dialogue programme ? » qui vous force à choisir « Oui » ou « Non » quand vous utilisez des mécanismes de gestion de protocoles (certains navigateurs vous autorisent à sauvegarder ce choix, mais pas tous... Microsoft Edge, c'est de toi que je parle...).
- Cliquez sur « Oui ».Dans le cas contraire, rien ne se passe.
- Lancez le client de jeu, qui réagit maintenant automatiquement grâce au mécanisme de protocole.
- Obtenez l'accès OAuth2 et les jetons d'actualisation grâce au flux authorization_code.
- Entrez dans le jeu.
Nous nous rapprochions de notre objectif. Nous utilisions à présent le flux authorization_code OAuth2 comme voulu. Cependant, nous nous retrouvions avec un affreux dialogue système que nous ne pouvions ni personnaliser, ni modifier d'aucune manière ! Et si l'utilisateur sélectionnait le bouton « Non », rien ne se passait et il fallait tout recommencer.
En outre, que se passerait-il si le jeu était déjà ouvert ? Devions-nous lancer une nouvelle instance ou faire passer l'autorisation à l'instance existante ? Les joueurs pouvaient déjà ouvrir le jeu RuneScape à partir du navigateur, bien sûr. Mais l'esprit du client de RuneScape reposait entièrement sur la possibilité de lancer autant d'instances que souhaité, plutôt que de garder un mécanisme de gestion ouvert pour une seule instance, ce qui posait un autre défi technique.
Deux stratégies pouvaient nous permettre d'éviter la boîte de dialogue :
- Le client de jeu devait exploiter un serveur Web sur l'ordinateur de l'utilisateur et le rediriger vers le navigateur. Avec cette solution, l'utilisateur se retrouvait dans la même situation que plus haut : il devait réaccéder au client de jeu manuellement à la fin de l'authentification. Nous l'avons donc écartée assez rapidement.
- Le client de jeu devait avoir son propre navigateur Web CEF (Chromium Embedded Framework). Nous en parlerons un peu plus loin.
Du bonheur en barre !
En insérant un navigateur dans le jeu, nous obtiendrions une expérience utilisateur entièrement personnalisable : pas de dialogue, pas besoin de passer manuellement d'une application à l'autre. À première vue, c'était exactement ce que nous cherchions, mais il y avait quelques hics. L'un d'eux est spécifique à RuneScape et les autres sont liés aux futures opportunités d'édition de Jagex.
- La taille de téléchargement relativement réduite du client de jeu a toujours fait notre fierté. En intégrant un navigateur Web CEF, le paquet téléchargeable allait doubler en taille – chose que nous voulions éviter, surtout pour une simple question d'authentification.
- Notre objectif initial était d'offrir une expérience d'authentification centralisée et unifiée pour se connecter à n'importe quel produit Jagex, y compris tous les futurs jeux, donc :
- Si nous ajoutions un navigateur à RuneScape, ne condamnions-nous pas tous les jeux publiés par Jagex et utilisant nos mécanismes d'authentification à faire de même ? Cela aurait pu poser de grandes difficultés pour les jeux n'ayant jamais envisagé d'intégrer un navigateur CEF.
- De plus, les navigateurs intégrés ont une faiblesse : l'application hôte (ici, le client de jeu) peut accéder aux nom d'utilisateur/adresse électronique et mot de passe à partir d'un code relativement simple. Dans le cas des jeux internes comme RuneScape, nous n'étions pas inquiets, car Jagex contrôle les normes de sécurité et nous pouvons conserver l'entière responsabilité de la sécurité de ces données. Mais si nous proposions ce mécanisme à des développeurs de jeux vidéo extérieurs à Jagex (via le programme Jagex Partners par exemple), cette responsabilité leur échoirait et ne serait plus du ressort de notre équipe interne. Ce n'était pas quelque chose que nous voulions imposer aux autres studios.
- Si jamais nous intégrions un navigateur dans plusieurs jeux, en cas de faille de sécurité dans l'un d'entre eux, tous les jeux sans exception devraient mettre à jour leur protection – une tâche titanesque qui ne ferait que croître avec le nombre des jeux ajoutés au fil du temps.
- L'intégration d'un navigateur dans chaque client nous empêcherait d'utiliser toute sorte de mécanisme de connexion unique à tous les jeux, car ils ne partageraient pas le stockage des jetons renvoyés. Dans un monde parfait, si vous vous connectez à RuneScape, vous devriez également être authentifié pour Old School et tous nos autres jeux, tel que Melvor Idle.
Une conclusion a fini par s'imposer à nous : bien qu'améliorant l'expérience utilisateur comparé au navigateur par défaut, l'intégration d'un navigateur directement dans le jeu n'était pas viable sur le long terme. Nous devions revenir sur une ancienne idée...
Une vieille idée refait surface
Vers la fin de l'année 2020, nous étions prêts à étudier la possibilité d'un launcher mais forts, cette fois, de plus d'expérience et de lucidité. Nous avons repris les concepts du navigateur intégré que nous avions étudiés, les avons appliqués à un launcher et découvert qu'ils collaient parfaitement avec nos objectifs ! Nous allions développer un launcher en utilisant un navigateur intégré dès le départ, mais qui ne se limiterait pas à l'authentification et à l'autorisation, et qui se servirait de l'interface utilisateur comme point de référence.
Repassons donc en revue les conditions évoquées plus haut et voyons comment le launcher nous permet de les respecter :
- Mécanisme d'autorisation standard — Avec un navigateur intégré dans le launcher, le flux authorization_code du protocole OAuth2 fonctionne parfaitement car il peut gérer les mêmes choses qu'un navigateur Web classique.
- Sécurité et prévention automatisée des attaques — Comme nous l'avons déjà mentionné, les leaders de l'industrie qui dispensent ces services fournissent des logiciels qui ne fonctionnent correctement que dans un navigateur et sur HTTP. Le launcher nous permet de nous mettre aux normes et d'intégrer sans difficulté les captchas, les WAF et la limitation de débit.
- Données de connexion sauvegardées — Le launcher étant aussi une application native, il est capable de stocker les jetons d'accès et d'actualisation du protocole OAuth2 en toute sécurité sur votre ordinateur. De plus, tous les jeux Jagex auxquels vous jouerez à l'avenir en bénéficieront également, de sorte que vous n'aurez plus jamais à entrer vos identifiants pour un nouveau jeu. Ils sauront automatiquement qui vous êtes !
- Expérience utilisateur fluide — Comme vous ne quittez jamais le navigateur pour entrer vos identifiants, vous n'aurez plus à passer manuellement d'une application à une autre, et plus aucune fenêtre de dialogue indésirable ne s'affichera pendant le processus de connexion.
- Téléchargement minimum du client de jeu — En utilisant un launcher pour l'authentification, les clients de jeu n'ont pas besoin d'intégrer d'autres fonctionnalités à cette fin, et la taille de téléchargement du jeu reste minimale.
- Responsabilité des données centralisées — Le launcher est et restera toujours sous le contrôle de Jagex. Jagex sera donc perpétuellement responsable de la sécurité de vos nom d'utilisateur/adresse électronique et mot de passe, avec des jetons OAuth2 envoyés aux jeux, qu'ils aient été développés en interne ou en externe par les équipes de développement de Jagex. Ceci signifie également que tous nos jeux bénéficieront des mises à jour, correctifs et améliorations des flux au même moment.
- Authentification unique dans tous nos jeux — Quel que soit le jeu Jagex auquel vous jouez, aujourd'hui comme à l'avenir, le launcher vous permettra systématiquement de le lancer. Il deviendra le lieu central abritant toutes les données d'autorisation et, si les joueurs souhaitent changer de jeu, ils n'auront pas à s'identifier à nouveau.
À ce stade, il devient clair que le launcher répond vraiment à toutes nos attentes, du point de vue de l'expérience utilisateur mais aussi de la sécurité. Il offre évidemment de nombreux autres avantages, notamment en termes de perspective et d'amélioration de l'expérience utilisateur, mais ceux-ci mériteraient un autre article à eux tout seuls...
C'est dans la boîte !
J'espère que cet article a répondu à toutes vos questions concernant notre processus de développement quant à la création du launcher, et qu'il vous a permis de mieux comprendre les défis que nous avons dû surmonter pour pouvoir vous le proposer. La sécurité de votre compte a toujours été notre priorité principale tout au long du projet, et nous voulions nous assurer que toutes vos interactions dans nos jeux restent aussi fluides que possible sans compromettre cette sécurité.
À l'avenir, nous aimerions vous parler davantage des autres fonctionnalités et avantages que comporte le launcher, et de la façon dont nous continuons à soutenir nos critères de sécurité et d'expérience utilisateur au fil du temps. Restez attentifs, car d'autres articles vous attendent bientôt. Et merci d'avoir pris le temps de me lire !