Jagex Launcher: Technical Newspost

Hi everyone, I'm Mod Shadow and I'm the Platform Architect for our Publishing Platform! Ever felt curious about the more technical aspects behind the Jagex Launcher? Well, today I can reveal the secrets about how it evolved over time into what you see currently!

Be warned, this article concentrates on highly technical details– we’re going in deep, folks! I'll also be linking to various other sources as we go, so you can read on even further if you're interested.

The year was 2016...

...and there were whispers in the studio of ideas for a launcher – a way of unifying our games under one banner. We even created a prototype, demonstrating how a player might install and launch both Old School and RuneScape from a central application on their humble Windows desktop.

Fast forward to mid-2017, and we had gathered a small team to begin building it. We had lofty ideas of players being able to maintain a longer-lived session of days and weeks, rather than the mere hours we had at the time, so people could quickly get into the games they love without needing to re-enter their username and password. Sound familiar?

RS Mobile

That same year, Jagex announced that we would be bringing both Old School and RuneScape to mobile – we, therefore, parked the launcher to concentrate on this for the time being. However, this new focus actually gave us new ideas for the launcher, because we were also looking at how to bring long-lived sessions to mobile devices. To this day, it’s possible to boot up both the iOS and Android app and just tap ’Play’ if you've logged in just once before. You can think of this mechanism as the first example of what we now provide in the launcher today, as it's fundamentally built (with a little Jagex magic) on the same core concepts.

Dipping our toes in

You may have heard of OAuth2; it's been around a little while. Even if you haven’t, you're likely using OAuth2 every day without realising it! Every time you log into something using your Google, Facebook, Twitter or even Twitch account, you're using it. It's not something Jagex invented and has been worked on for many years by security professionals to provide a watertight method of authorising you to use software. It’s trusted and used by thousands of software companies to keep their accounts as safe as possible.

However, RuneScape has also been around for a good long while, and it already had a very well-established way of logging users in, with certain user experience expectations built in too. So, we had to ease our way into utilising a new mechanism carefully. OAuth2 comes with two types of tokens; an Access Token, which is used to authorise network calls, and a Refresh Token, which is used to get a new Access Token when the existing one expires. It's these tokens that give us the ability to log you back into the game, even if you haven't played for days on mobile. In order to maintain our existing user experience at the time, we utilised OAuth2's extension specification and hooked in our existing login processes to generate these tokens. This was our first step towards a new way of logging in. We introduced this feature as part of the mobile beta and subsequent launch of Old School on mobile in 2018.

Evolution

At this point, we were just barely starting to use OAuth2 mechanisms to log people into the game. We knew that we wanted to utilise the standard OAuth2 flows to log people in without having to use the extension we were currently using. Utilising one of the standard flows, i.e., authorization_code, had several benefits:

• We could enforce a principle of least privilege - only one location would be responsible for your username and password, rather than entering it in multiple locations (e.g. Website, OSRS Game Client & RS Game Client), this way nothing else ever needs to know your sensitive login details.
• We could unify the login process, providing the same user experience no matter whether you were logging into Old School or RuneScape. It would also allow us to centralise ways of logging in (across Google, Apple and Facebook) without needing to update the game client substantially – or even at all!
• We could implement strict security controls and use industry-leading software to protect against malicious users effectively because it would only be a single place, and it used the HTTP protocol rather than the custom protocol our game clients used.
• It would pave the way for us to integrate other systems we develop to have logged-in functionality more quickly than the custom methods that were being used previously.

However, this presented both a technical and user experience challenge. OAuth2 expects to be handled by a web browser, something that can render HTML, CSS, JavaScript, store cookies and deal with HTTP responses, these aren't things that are performed directly by a game client.

Given that the mobile client was already capable of dealing with OAuth2 tokens we decided, once again, to tackle it there first.

Browser Login on Mobile

We focused on mobile first because we had already made progress utilising OAuth2 tokens with success on that platform, so it made sense to enhance the flow there before trying to recreate it anywhere else. Both Android and iOS have very good support for this kind of flow, specifically providing features to enable OAuth2 via specialised browser windows (Trusted Web Activity and ASWebAuthenticationSession respectively) that could be launched from phone apps.

We already had a login experience that people knew from the browser which we like to call the ’web login flow’. People had used this process for years to log in and manage their accounts, post on the forums, or subscribe. It therefore made sense for us to re-use that where we could. We spent a fair amount of time with the game teams from both RuneScape and Old School to ensure that we used all the right security controls on the specialised browser windows mentioned above. We wanted to get to a place where we had a working mechanism

to log people in via the same website they trust, get OAuth2 access and refresh tokens via a standardised OAuth2 authorization_code flow and log into the game on mobile successfully.

In December 2020, for the first time ever, people who logged in on mobile went through this new flow – supported by the same protections we had in front of our website logins! Things like captcha, WAF, rate limiting and other standardised protections only achievable through a browser and HTTP network calls were now protecting logins to the mobile game.

And now for our next trick!

We were in a good place with Old School on mobile: we had the ability to tweak and add further protections to login, we had those all-important remembered logins and all the other benefits I mentioned earlier, and when it came to releasing RuneScape on mobile in 2021 it was very straight forward to integrate it with the OAuth2 flow. But how would we get these same benefits on desktop?

Unlike Android and iOS, Windows does not have a specialised browser window that can be used in the same seamless fashion. Instead, a user can have multiple browsers which do not have first party support from the operating system. So, we experimented with using the user's default browser, in a similar way to how we handle Apple and Google logins on desktop.

The principle was simple:

1. Double-click desktop icon.
2. Start the game client.
3. Click ‘Login’.
4. Open the browser.
5. Authenticate.
6. Direct back to the game client.
7. Enter the game with the oauth2 access and refresh tokens.

In practice though, the experience left something to be desired. What you actually end up with is:

1. Double-click desktop icon.
2. Start the game client.
3. Click ‘Login’.
4. Open the browser.
5. Pray the browser will take focus.
6. Authenticate.
7. Receive a ’Success, you logged in!’ message.
8. Have the user manually navigate back to the client.
9. Wait for the login process to finish.
10. Retrieve OAuth2 access and refresh tokens via the old method.
11. Enter the game.

We looked at trying to remove some of the steps. Instead of the game client starting first, why not the browser? And instead of utilising the same mechanisms Apple and Google logins use, we looked at starting the client with protocol handlers. Let’s see how that plays out:

1. Double click the desktop icon.
2. Open the browser.
3. Authenticate.
4. Receive ‘Success’ message.
5. Receive ’Are you sure you want to open this program dialog?’ message that forces users to choose ‘yes’ or ‘no’ when using protocol handlers (some browsers allow you to remember this choice, but others don't… we’re looking at you Microsoft Edge...)
6. Click the ’Yes I'm sure; button – if you don't, nothing happens.
7. Start the game client, which now takes focus automatically thanks to the protocol handler.
8. Retrieve OAuth2 access and refresh tokens via the authorization_code flow.
9. Enter the game.

This was closer to what we wanted. We're using the OAuth2 authorization_code flow as intended now. However, we've also now got a horrible system dialog that we can't style or change in any way! Plus, if the user selects no, then nothing ever happens, and they're forced to start again.

Also, what happens if the game is already open? Should we start a new instance or pass the authorisation to the existing instance? RuneScape already has a way of opening the game from the browser, of course. But the whole ethos of RuneScape's client is built around running as many instances as you want, rather than keeping a handler open to just one, making this a tricky technical challenge.

There are a couple of strategies which would allow us to avoid the dialog altogether:

• Have the game client run a web server on the user's computer and redirect to that in the browser. With this solution, we would end up in the same situation where the user had to manually switch back to the game client once they finished authenticating, so we ruled this out pretty quickly.
• Have the game client bundle its own CEF (Chromium Embedded Framework) web browser, which we'll discuss further below.

What a bundle of fun!

If we bundled a browser in with the game, this would give us a UX which we could completely customise – no dialogue, no need for the user to manually swap between applications. On the face of it, this seemed like everything we wanted, but there are a few caveats. One is RuneScape-specific, and the others are presented with an eye to future Jagex publishing opportunities.

1. We’ve always prided ourselves on maintaining a relatively small download size for the game client. Bundling something like CEF would more than double the downloadable package – something we wanted to avoid, especially if it’s only for authentication purposes.
2. We said originally that our aim was to have a centralised and unified authentication experience when logging into any Jagex product, and that this would include future games, so:

• If we bundled a browser into RuneScape, were we then dictating that all games published by Jagex and using our authorization mechanisms would need to do so as well? This could be a significant integration pain point if a game never considered needing CEF initially.
• A weakness of an embedded browser is that with some relatively straightforward code, the hosting application (i.e. the game client) can access the username/email and password. In the case of first-party games like RuneScape, this was less of a concern as Jagex was in control of the security standards and we could maintain responsibility for the security of those credentials. As soon as we provide this mechanism to game developers other than Jagex, like via the Jagex Partners Scheme, we'd be pushing the responsibility for maintaining security around credentials in that part of the flow to them, and not our internal staff. This wasn't a responsibility we wanted other studios to have to take on.
• If multiple games have embedded a browser, should a security vulnerability be discovered in that embedded browser technology, all games would need to update to protect you effectively – a mammoth task that only grows the more games we add.

It became clear that while it may give a better user experience than the default browser approach we considered previously, bundling a browser directly into a game wasn't feasible long term. We needed to revisit an old idea...

An old idea resurfaces

Towards the end of 2020 we were ready to discuss the prospect of a launcher, only this time with much more experience and focus. We took the same concepts we discussed about an embedded browser above and applied them instead to a launcher, and found that it fit our use cases and user experience goals perfectly. This launcher would be developed using an embedded browser from the start, one that would be used for more than just authentication and authorisation – and would set the overall user interface as a baseline.

So let’s run through the requirements we mentioned above, and show how the launcher enables us to meet them:

1. Standard authorization mechanism – with the launcher embedding a browser, the OAuth2 authorization_code flow works out of the box as it can handle all the things a normal web browser can.
2. Security and automated attack prevention – as we mentioned before, industry leaders who offer these services provide software which only works properly in a browser and over HTTP. The launcher allows us to standardise with things like Captchas, WAF, rate limiting integrating seamlessly.
3. Remembered logins – because the launcher is also a native application, it's capable of storing the OAuth2 Access and Refresh tokens securely on your computer, so remembering your logged in session is both straight forward and secure. Best of all any Jagex game you play in the future gets it for free too, so you never have to enter your credentials again for a new game. It will just know who you are!
4. Seamless user experience – as you never leave the launcher to enter your credentials, there's no risk of a user needing to manually switch applications, and no nasty dialogs popping up during the login process.
5. Minimum game client download – by using a launcher to serve authorization purposes, the game clients no longer need to bundle anything extra for this purpose, and can maintain the minimalist game download size.
6. Centralised credential responsibility – the launcher is now, and will always be, under the developmental control of Jagex. This means Jagex will always remain responsible for the security of your username/email and password, with OAuth2 tokens passed to games instead regardless of whether the game was developed internally or externally to Jagex's development teams. It also means that all our games get updates, fixes, improvements to the flows at the same time.
7. SSO across our games – no matter what Jagex game someone plays, now or in the future, they will always have the launcher to start it. It becomes a centralised location for authorization credentials to reside and if players want to swap to a different game, they don't need to authenticate again.

At this point, hopefully it becomes clear that the launcher delivers exactly what we wanted to achieve, both from a user experience and a security perspective. There are of course numerous other benefits that it also brings in terms of insight and user experience optimisations, but perhaps those are for another blog…

That's a wrap!

I hope this gives you an insight into some of our developmental process when it came to creating a launcher, and the challenges we needed to overcome in delivering it to you. We made sure that your account's security was our top priority every step along the way, as well as making sure that every interaction you have with our games is as seamless as it can be without compromising that security.

Going forward, we'd like to talk more about the additional features and benefits the launcher brings our players, and how we're continuing to support this vision of security and user experience into the future. Keep an eye out for more insights soon – and thanks for reading!

- Mod Shadow & the Publishing Platform Development Team