Entwicklungstagebuch: Der Jagex Launcher

Hallo! Ich bin Mod Shadow und ich bin der „Platform Architect“ für unsere Publikationsplattform! Warst du schon immer mal neugierig, was die technischen Aspekte des Jagex Launchers angeht? Heute werde ich das Geheimnis lüften, wie er sich im Lauf der Zeit zu dem entwickelt hat, was er heute ist!

Achtung: In diesem Artikel geht es um sehr viele technische Details – stürzen wir uns hinein! Ich werde im Artikel auch andere Quellen verlinken, sodass du bei Interesse noch mehr darüber lesen kannst.

Wir schrieben das Jahr 2016...

... und im Studio kursierten Gerüchte über einen Launcher – eine Möglichkeit, unsere Spiele unter einem Banner zu vereinen. Wir entwickelten sogar einen Prototyp, der demonstrierte, wie Spieler*innen mit einer einzigen Anwendung auf der Windows-Benutzungsoberfläche sowohl Old School als auch RuneScape starten können.

Bis Mitte 2017 hatten wir ein kleines Team zusammengestellt, um den Launcher in die Tat umzusetzen. Wir hatten ehrgeizige Ideen, dass Spieler*innen eine Spielsitzung Tage oder Wochen würden nutzen können, statt bloß ein paar Stunden, wie es damals der Fall war. So würden Spieler*innen schnell ihre Lieblingsspiele starten können, ohne ihren Anmeldenamen und ihr Passwort erneut einzugeben. Kommt dir das bekannt vor?

RuneScape Mobile

Im gleichen Jahr gab Jagex bekannt, dass sowohl Old School als auch RuneScape auf Mobilgeräten erscheinen würde. Deshalb stellten wir den Launcher vorerst zurück und konzentrierten uns darauf. Durch unser neues Ziel hatten wir aber auch neue Ideen für den Launcher – denn wir überlegten, wie wir langfristige Spielsitzungen auf Mobilgeräten umsetzen konnten. Bis zum heutigen Tag ist es möglich, die iOS- und die Android-App zu starten und einfach auf „Spielen“ zu tippen, wenn du dich schon einmal angemeldet hast. Dieser Mechanismus ist quasi ein erstes Beispiel für die Funktionen, die wir heute über den Launcher anbieten. Im Grunde basiert er auf den gleichen Konzepten (und ein bisschen Jagex-Magie).

Erste Schritte

Vielleicht hast du schon von OAuth2 gehört – das gibt es schon seit einiger Zeit. Auch wenn du noch nicht davon gehört hast, benutzt du OAuth2 wahrscheinlich täglich, ohne dir dessen bewusst zu sein! Jedes Mal, wenn du dich mit deinem Google-, Facebook-, Twitter- oder sogar mit deinem Twitch-Konto irgendwo anmeldest, benutzt du OAuth2. OAuth2 wurde nicht von Jagex erfunden – Expert*innen für IT-Sicherheit arbeiten seit Jahren daran, um Nutzer*innen eine hieb- und stichfeste Methode zur Autorisierung von Softwarebenutzung zu bieten. Tausende von Software-Firmen setzen ihr Vertrauen in OAuth2, um ihre Konten so gut wie möglich zu schützen.

Allerdings gibt es RuneScape auch schon etwas länger und damit eine lang etablierte Methode zum Anmelden von Benutzer*innen, die auch gewisse Erwartungen für das Nutzungserlebnis mit sich brachten. Also mussten wir uns dem neuen Mechanismus behutsam nähern. Bei OAuth2 gibt es zwei Arten von Token: ein Access-Token, das zur Autorisierung von Netzwerk-Anfragen dient, und ein Refresh-Token, das ein neues Access-Token gewährt, wenn das aktuelle abgelaufen ist. Diese Token ermöglichen es uns, dich erneut im Spiel anzumelden, auch wenn du mehrere Tage lang nicht auf einem Mobilgerät gespielt hast. Weil wir an unserem damaligen Nutzungserlebnis festhalten wollten, benutzten wir die Verlängerungsspezifikation von OAuth2 und verbanden sie mit unseren bestehenden Anmeldeprozessen, um diese Token zu generieren. Das war der erste Schritt auf dem Weg zu einem neuen Anmeldevorgang. Diese Funktion wurde dann im Rahmen der Mobile-Beta und bei der späteren Veröffentlichung von Oldschool Mobile 2018 implementiert.

Weiterentwicklung

Zu diesem Zeitpunkt kratzten wir nur an der Oberfläche der OAuth2-Mechanismen, um Benutzer*innen im Spiel anzumelden. Wir wussten, dass wir die normalen OAuth2-Flows nutzen wollten, damit Leute sich anmelden konnten, ohne die Verlängerung benutzen zu müssen, die wir zu dem Zeitpunkt verwendeten. Die Verwendung von einem Standard-Flow (authorization_code) bot folgende Vorteile:

• Wir konnten das Prinzip der geringsten Rechte nutzen: So wäre nur eine Location für deinen Loginnamen und dein Passwort zuständig, statt sie an mehreren Locations (z.B. auf der Webseite, im OSRS-Spielclient und im RS-Spielclient) einzugeben. So mussten andere Locations deine vertraulichen Anmeldedaten gar nicht kennen.
• Wir konnten den Anmeldevorgang vereinheitlichen und so Spieler*innen das gleiche Nutzungserlebnis bieten, egal, ob sie sich bei Old School oder RuneScape anmeldeten. So würde es auch möglich sein, den Anmeldevorgang (bei Google, Apple und Facebook) zu zentralisieren, ohne den Spielclient groß aktualisieren zu müssen – wenn überhaupt!
• Wir konnten strenge Sicherheitsmaßnahmen implementieren und branchenführende Software nutzen, um uns effektiv gegen böswillige Benutzer*innen zu schützen, da es sich nur um eine Location handelte und diese das HTTP-Protokoll anstelle des eigenen Protokolls unseres Spielclients nutzte.
• Dies würde den Weg dafür ebnen, schneller andere von uns entwickelte Systeme zu integrieren, samt Funktionalität zur langfristigen Anmeldung, statt unserer eigenen Methoden, die wir bisher benutzt hatten.

Allerdings stellte uns das vor eine Herausforderung, sowohl was die Technik als auch das Nutzungserlebnis anging. OAuth2 erwartet, von einem Web-Browser benutzt zu werden: etwas, das HTML, CSS, JavaScript rendern, Cookies speichern und mit HTTP-Antworten umgehen kann. Das sind Sachen, die ein Spielclient nicht direkt ausführt.

Da der Mobile-Client bereits mit OAuth2-Token umgehen konnte, beschlossen wir, es als Erstes wieder mit ihm zu probieren.

Anmeldung im Browser auf Mobilgeräten

Wir haben uns zuerst auf Mobilgeräte konzentriert, weil wir auf der Plattform bereits Erfolg mit der Nutzung von OAuth2-Token hatten. Deswegen lag es nahe, den Flow dort zu erweitern, bevor wir versuchten, ihn anderswo nachzubauen. Android und iOS bieten sehr gute Unterstützung für solche Flows, wie etwa Funktionen, um OAuth2 über spezielle Browserfenster zu ermöglichen („Trusted Web Activity“ und „ASWebAuthenticationSession“), die von Handy-Apps aus gestartet werden können.

Wir hatten bereits einen Anmeldevorgang, den die Spieler*innen vom Browser kannten. Wir nennen es den Web-Anmelde-Flow. Die Spieler*innen hatten jahrelang diesen Vorgang benutzt, um sich anzumelden und ihre Konten zu verwalten, im Forum zu posten oder Mitglied zu werden. Daher war es unserer Meinung nach sinnvoll, ihn so weit wie möglich zu benutzen. Wir verbrachten viel Zeit mit den Entwicklungsteams von RuneScape und Old School, um sicherzustellen, dass wir die passenden Sicherheitsmaßnahmen für die oben erwähnten Browserfenster benutzen.

Unser Ziel war ein funktionierender Mechanismus, mit dem Spieler*innen sich über die vertraute Webseite anmelden, OAuth2-Access- und Refresh-Token (mithilfe eines standardisierten OAuth2-„authorization_code“-Flow) erhalten und sich erfolgreich auf Mobilgeräten im Spiel anmelden.

Im Dezember 2020 benutzten Spieler*innen, die sich auf Mobilgeräten anmeldeten, zum allerersten Mal diesen Ablauf – unterstützt von den gleichen Sicherheitsmaßnahmen, die wir für unsere Webseiten-Anmeldung implementiert hatten! Dinge wie Captcha, WAF, Durchsatzratenbegrenzung und andere standardisierte Schutzmechanismen, die nur per Browser und HTTP-Netzwerk-Anfragen möglich waren, schützten jetzt den Anmeldevorgang für das Spiel auf Mobilgeräten.

Und nun zu unserem nächsten Trick!

Für Oldschool Mobile sah es gut aus: Wir konnten die Sicherheitsmaßnahmen für den Anmeldevorgang weiter verfeinern und neue hinzufügen. Wir hatten die wichtige langfristige Anmeldung sowie alle anderen Vorteile, die ich schon erwähnt hatte. Als wir RuneScape Mobile dann 2021 veröffentlichten, war es sehr simpel, es in den OAuth2-Ablauf zu integrieren. Aber wie konnten wir die gleichen Vorteile auf dem PC nutzen?

Im Gegensatz zu Android und iOS gibt es für Windows kein spezielles Browserfenster, das genauso einfach verwendet werden kann. Stattdessen können Benutzer*innen mehrere Browser verwenden, für die es keine Unterstützung durch das Betriebssystem gibt. Also haben wir mit dem Standardbrowser der Nutzenden experimentiert, so ähnlich wie wir die Apple- und Google-Anmeldung auf dem PC handhaben.

Das Prinzip war simpel:

1. Auf das Symbol auf der Benutzungsoberfläche doppelklicken
2. Den Spielclient starten
3. Auf „Einloggen“ klicken
4. Den Browser öffnen
5. Authentifizieren
6. Umlenkung zurück zum Spielclient
7. Das Spiel mit den OAuth2-Access- und Refresh-Token betreten

In der Praxis ließ der Vorgang allerdings zu wünschen übrig. In Wirklichkeit lief es wie folgt ab:

1. Auf das Symbol auf der Benutzungsoberfläche doppelklicken
2. Den Spielclient starten
3. Auf „Einloggen“ klicken
4. Den Browser öffnen
5. Beten, dass der Browser im Fokus ist
6. Authentifizieren
7. Benutzer*in erhält Nachricht: „Du hast dich erfolgreich eingeloggt!“
8. Benutzer*in muss manuell wieder zurück zum Client navigieren
9. Warten, dass der Anmeldevorgang abgeschlossen ist
10. OAuth2-Access- und Refresh-Token anhand der alten Methode erhalten
11. Das Spiel betreten

Wir überlegten, wie wir ein paar der Schritte überspringen konnten. Warum sollte nicht der Browser zuerst gestartet werden, statt des Spielclients? Und statt die gleichen Mechanismen wie Apple und Google zur Anmeldung zu benutzen, experimentierten wir damit, den Client mit Protokollhandlern zu starten. Das läuft dann wie folgt:

1. Auf das Symbol auf der Benutzungsoberfläche doppelklicken
2. Den Browser öffnen
3. Authentifizieren
4. Benutzer*in erhält Nachricht, dass der Vorgang Erfolg hatte
5. Erhalt der Nachricht „Bist du sicher, dass du diesen Programmdialog öffnen möchtest?“, die Nutzende dazu zwingt, bei der Verwendung von Protokollhandlern „Ja“ oder „Nein“ auszuwählen. (Manche Browser lassen zu, dass die Einstellung gespeichert wird, andere dagegen nicht... ja, Microsoft Edge, wir reden von dir...)
6. Auf den Button „Ja, ich bin mir sicher“ klicken – sonst passiert nichts
7. Spielclient starten, der jetzt dank des Protokollhandlers automatisch im Fokus ist
8. OAuth2-Access- und Refresh-Token über den „authorization_code“-Flow erhalten
9. Das Spiel betreten

Das kam dem schon etwas näher, wie wir es uns vorgestellt hatten. Jetzt nutzen wir den OAuth2-“authorization_code“-Flow wie vorgesehen. Leider haben wir jetzt aber auch einen furchtbaren Systemdialog, den wir nicht modifizieren können! Und wenn die Nutzenden „Nein“ auswählen, passiert überhaupt nichts und sie müssen wieder von vorn beginnen.

Und was passiert, wenn das Spiel bereits läuft? Sollten wir eine neue Instanz starten oder die Autorisierung auf die vorhandene Instanz übertragen? Für RuneScape gibt es natürlich schon einen Weg, das Spiel aus dem Browser zu öffnen. Aber der RuneScape-Client wurde so entwickelt, dass man so viele Instanzen wie gewünscht haben kann, statt dass ein Handler nur einen geöffnet hat, was eine technische Herausforderung darstellt.

Es gibt ein paar Strategien, mit deren Hilfe wir den Dialog ganz umgehen könnten:

• Über den Spielclient einen Web-Server auf dem PC der Benutzer*innen laufen lassen und im Browser auf diesen umlenken. Mit dieser Lösung hätten wir wieder die Situation, dass die Benutzer*innen manuell zum Spielclient zurückwechseln müssen, sobald die Authentifizierung abgeschlossen ist, weshalb wir uns schnell dagegen entschieden haben.
• Den CEF-Webbrowser (Chromium Embedded Framework) in den Spielclient integrieren, dazu unten mehr

Was für ein Spaß!

Wenn wir einen Browser in das Spiel integrieren würden, hätten wir ein Nutzungserlebnis, das wir frei gestalten könnten – ohne Dialog, und ohne dass die Benutzer*innen manuell zwischen den Anwendungen hin- und herwechseln müssen. Auf den ersten Blick schien das DIE Lösung zu sein, aber es gab noch ein paar Haken. Einer davon gilt spezifisch für RuneScape, und die anderen beziehen sich auf zukünftige Publishing-Projekte von Jagex.

1. Wir waren immer stolz darauf, dass der Download-Umfang für den Spielclient relativ klein war. Die Integration eines CEF würde den Download mehr als verdoppeln – was wir vermeiden wollten, vor allem, wenn es nur der Authentifizierung dient.
2. Ursprünglich war es unser Ziel, einen zentralisierten Authentifizierungsvorgang für die Anmeldung bei sämtlichen Jagex-Produkten zu haben, was auch zukünftige Spiele umfasst. Das heißt:
• Wenn wir einen Browser in RuneScape integrieren, schreiben wir dann vor, dass alle von Jagex veröffentlichten Spiele und solche, die unsere Autorisierungs-Mechanismen nutzen, dies auch tun müssen? Das könnte ein erheblicher Störfaktor für die Integration sein, wenn ein Spiel nicht so angelegt ist, dass es von vornherein CEF benötigt.
• Ein Nachteil eines integrierten Browsers besteht darin, dass mit etwas unkompliziertem Code die Hosting-Anwendung (also der Spielclient) Zugriff auf den Anmeldenamen/die E-Mail-Adresse und das Passwort haben kann. Bei unseren eigenen Spielen wie RuneScape war das nicht wirklich ein Problem, da Jagex für die Sicherheitsmaßnahmen zuständig war und wir somit die Verantwortung für die Sicherheit der Zugangsdaten hatten. Sobald wir diesen Mechanismus aber mit anderen Spielentwickler*innen (etwa über Jagex Partners) teilen, die nicht für Jagex arbeiten, würden wir die Verantwortung hinsichtlich der Sicherheit der Zugangsdaten für diesen Teil des Vorgangs an sie übertragen und unsere internen Mitarbeiter*innen würden sie verlieren. Wir wollten nicht, dass andere Studios diese Verantwortung übernehmen müssen.
• Hätten mehrere Spiele einen integrierten Browser und gäbe es dann eine Sicherheitsschwachstelle in der integrierten Browsertechnologie, müssten sämtliche Spiele aktualisiert werden, um die Spieler*innen effektiv zu schützen – eine monumentale Aufgabe, die mit weiteren neuen Spielen noch umfangreicher werden würde.
3. Ein integrierter Browser in jedem Client würde verhindern, dass wir einen Einmalanmeldungs-Mechanismus für alle Spiele verwenden, da integrierte Browser keinen gemeinsamen Speicher haben. Optimal wäre es, wenn man sich bei RuneScape anmelden würde und damit auch bei Old School und anderen Spielen, die wir veröffentlichen (wie etwa Melvor Idle) authentifiziert wäre.

Uns wurde klar, dass ein integrierter Browser langfristig für uns nicht durchsetzbar sein würde, auch wenn wir so das Nutzungserlebnis verbessern würden – verglichen mit der Standard-Browser-Methode, die wir vorher in Betracht gezogen hatten. Wir mussten auf eine ältere Idee zurückgreifen...

Eine ältere Idee kommt wieder zum Vorschein

Gegen Ende 2020 waren wir bereit, über einen Launcher zu reden – dieses Mal aber mit sehr viel mehr Erfahrung und Fokus. Wir nahmen die Konzepte, die wir weiter oben für einen integrierten Browser besprochen hatten, und nutzten sie stattdessen für einen Launcher. Uns wurde klar, dass er perfekt zu unseren Anwendungsfällen und Zielen hinsichtlich des Nutzungserlebnisses passte. Der Plan war, den Launcher von Anfang an mit einem integrierten Browser zu entwickeln, der nicht nur für Authentifizierung und Autorisierung benutzt werden würde. Und sein Benutzungsinterface würde die Basis darstellen.

Gehen wir noch mal die Voraussetzungen durch, die wir oben erwähnt hatten. So können wir zeigen, wie der Launcher sie erfüllt:

1. Standard-Autorisierungsmechanismus – Mit einem integrierten Browser im Launcher funktioniert der OAuth2-“authorization_code“-Flow wie vorgesehen, da er alles machen kann, was ein normaler Webbrowser auch macht.
2. Sicherheit und Verhinderung automatischer Angriffe – Wie bereits erwähnt, funktioniert die entsprechende Software von Branchenführern nur richtig in einem Browser und mit HTTP. Dank des Launchers ist Standardisierung möglich, da sich Sachen wie Captchas, WAF und Durchsatzratenbegrenzung problemlos integrieren lassen.
3. Langfristige Anmeldung – Da es sich bei dem Launcher um eine native App handelt, kann sie die OAuth2-Access- und Refresh-Token sicher auf deinem Computer speichern. So ist die Sitzung, zu der du dich angemeldet hast, langfristig und sicher verwendbar. Und das Beste daran: Jedes Jagex-Spiel, das du in Zukunft spielen wirst, benutzt ihn ebenfalls. Du musst deine Zugangsdaten also nie wieder für ein neues Spiel eingeben. Er wird einfach wissen, wer du bist!
4. Einwandfreies Nutzungserlebnis – Da man nie vom Launcher wegschalten muss, um die eigenen Zugangsdaten einzugeben, läuft man kein Risiko, dass ein*e Nutzer*in manuell zwischen Anwendungen hin- und herwechseln muss oder dass während des Anmeldevorgangs irgendwelche unerwünschten Dialoge erscheinen.
5. Minimaler Spielclient-Download – Indem wir einen Launcher zur Autorisierung benutzen, muss nichts in den Spielclient integriert werden. So bleibt der minimale Umfang des Downloads erhalten.
6. Zentralisierte Verantwortung für Zugangsdaten – Der Launcher wird von Jagex entwickelt und ist damit immer unter unserer Kontrolle. Das bedeutet, dass Jagex immer für die Sicherheit deines Anmeldenamens/deiner E-Mail-Adresse und deines Passworts verantwortlich sein wird. Die OAuth2-Token werden an Spiele weitergegeben, ohne dass es eine Rolle spielt, ob es intern (von Jagex) oder extern entwickelt wurde. Außerdem bedeutet es, dass all unsere Spiele gleichzeitig Flow-Aktualisierungen, -Verbesserungen und -Patches erhalten.
7. Einmalanmeldung für alle unsere Spiele – Egal, welches Jagex-Spiel jemand spielt, ob jetzt oder in Zukunft, es kann immer mit dem Launcher gestartet werden. Er wird zu einer zentralisierten Location für die Autorisierungsdaten, und wenn Spieler*innen zu einem anderen Spiel wechseln möchten, müssen sie die Autorisierung nicht erneut ausführen.

Jetzt ist es hoffentlich offensichtlich, dass der Launcher genau das leistet, was wir erreichen wollten, sowohl von der Perspektive des Nutzungserlebnisses als auch von der Sicherheit her. Außerdem bietet er natürlich zahlreiche andere Vorteile, wie etwa Einblicke und Nutzungserlebnis-Optimierungen, aber das sollten wir uns vielleicht für einen weiteren Blog aufheben...

Das war alles!

Ich hoffe, du konntest einen Einblick in unseren Entwicklungsprozess für den Launcher gewinnen, und in die Herausforderungen, die wir dafür meistern mussten. Bei jedem einzelnen Schritt war es unsere oberste Priorität, die Sicherheit der Spielkonten zu gewährleisten. Außerdem wollten wir sicherstellen, dass die Benutzung unserer Spiele so einfach wie möglich ist, ohne dabei die Sicherheit aufs Spiel zu setzen.

In Zukunft würden wir gern noch weiter erklären, welche zusätzlichen Funktionen und Vorteile der Launcher unseren Spieler*innen bietet und wie wir unsere Vision hinsichtlich Sicherheit und Nutzungserlebnis auch in Zukunft unterstützen möchten. Halte Ausschau nach weiteren Blogs in nächster Zeit – und danke fürs Lesen!

---

– Mod Shadow und das Publikationsplattform-Entwicklungsteam