Olá, pessoal. Aqui é o Mod Shadow, responsável pela arquitetura da nossa plataforma de distribuição! Quem aí já quis saber mais sobre os aspectos técnicos por trás do Jagex Launcher? Bem, hoje vou revelar os segredos de como ele evoluiu ao longo do tempo até ganhar a forma atual que todos conhecem!
Mas já fica de aviso: este artigo se concentra em detalhes altamente técnicos. Ficar só na superfície não tem graça nenhuma! Também vou disponibilizar links para várias fontes ao longo do caminho. Assim, quem tiver interesse pode ir atrás de conhecer o assunto mais a fundo.
O ano era 2016...
... e boatos circulavam pelo estúdio falando de um launcher – uma forma de unificar nossos jogos sob uma única bandeira. Chegamos a criar um protótipo, mostrando como seria possível instalar e abrir o Old School e o RuneScape de um aplicativo central até no computador mais humilde com Windows.
Em meados de 2017, formamos uma equipe pequena para começar a trabalhar nele. Tínhamos planos grandiosos de permitir que o jogador mantivesse sessões por dias, talvez semanas, em vez de apenas horas, para que todos pudessem entrar rapidamente nos jogos que adoram sem precisarem informar nome de usuário e senha toda vez. Já viram isso em algum lugar?
RS Versão Móvel
No mesmo ano, a Jagex anunciou que tanto o Old School quanto o RuneScape chegariam aos dispositivos móveis. Com isso, deixamos o launcher de lado para nos concentrar nesse novo projeto. No entanto, esta acabou sendo uma boa fonte de novas ideias para o launcher, pois estávamos estudando uma forma de trazer sessões de longa duração para dispositivos móveis. Até hoje, quem já tiver entrado no jogo uma vez que seja pode abrir o aplicativo no iOS e no Android e simplesmente tocar em "Jogar". Esse mecanismo pode ser visto como o primeiro exemplo do que oferecemos com o launcher de hoje, uma vez que é construído com base nos mesmos conceitos básicos (e um toque de magia da Jagex).
Nos aprofundando
Você já deve ter ouvido falar do OAuth2; já faz algum tempo que ele existe. Mesmo se for novidade para alguém, é provável que você use o OAuth2 todo dia sem saber! Sempre que faz login na sua conta do Google, Facebook, Twitter ou até da Twitch, você faz uso dele. Ele não é criação da Jagex e tem sido aprimorado há anos por profissionais de segurança para oferecer um método inviolável de autorização de uso de software. É um recurso confiável, usado por milhares de companhias de software para elevar ao máximo a segurança de suas contas.
Porém, o RuneScape também está na praça faz um bom tempo e já contava com uma forma bem estabelecida de fazer o login dos usuários, consolidando algumas expectativas no que dizia respeito à experiência do usuário. Por isso, o uso de um novo mecanismo requeria alguma cautela. O OAuth2 conta com dois tipos de tokens: um Token de Acesso, usado para autorizar chamadas de rede; e um Token de Atualização, usado para fornecer um novo Token de Acesso quando o existente expira. São esses tokens que permitem conectar a pessoa de volta ao jogo mesmo depois de dias sem jogar no dispositivo móvel. Para manter a experiência de usuário que já tínhamos na época, utilizamos a especificação de extensão do OAuth2 e incorporamos aos nossos processos de login para gerar os tokens. Foi o primeiro passo que demos na direção de uma nova forma de fazer login. Introduzimos esse recurso como parte do beta da versão móvel e do lançamento do Old School para dispositivos móveis na sequência, em 2018.
Evolução
Nessa época, estávamos só começando a usar os mecanismos do OAuth2 para conectar as pessoas ao jogo. Sabíamos que queríamos usar os fluxos-padrão do OAuth2 para conectar as pessoas sem ter que usar a extensão que estávamos usando. Utilizar um dos fluxos-padrão, como o authorization_code, por exemplo, tinha vários benefícios:
- Podíamos aplicar um princípio de privilégio menor, com apenas um local responsável pelo seu nome de usuário e sua senha, em vez de ter que informar esses dados em vários lugares (p. ex., site, cliente do OSRS e cliente do RS). Assim, nada mais precisa conhecer seus dados de login, informações que são sensíveis.
- O processo de login podia ser unificado, oferecendo a mesma experiência de usuário ao fazer login no Old School ou no RuneScape. Isso também nos permitiria centralizar as formas de login (entre Google, Apple e Facebook) sem precisar fazer uma atualização do cliente, por menor que fosse!
- Podíamos implementar controles de segurança rigorosos e usar software de ponta para fornecer proteção contra usuários mal-intencionados de forma eficaz, pois seria um único lugar, que usava o protocolo HTTP, em vez do protocolo personalizado que os nossos clientes de jogo usavam.
- Isso pavimentaria o caminho para uma integração de outros sistemas desenvolvidos por nós à funcionalidade de login mais rápido que os métodos personalizados que usávamos antes.
No entanto, havia também um desafio do ponto de vista técnico e da experiência de usuário. O OAuth2 espera ser operado por um navegador da web, algo capaz de renderizar HTML, CSS e JavaScript, armazenar cookies e lidar com respostas do HTTP, coisas que não são feitas diretamente por um cliente de jogo.
Como o cliente para dispositivos móveis já era capaz de lidar com tokens do OAuth2, decidimos, mais uma vez, começar a trabalhar com ele lá primeiro.
Login pelo browser em dispositivos móveis
Nos concentramos em dispositivos móveis primeiro porque já tínhamos feito progresso na utilização de tokens do OAuth2 na plataforma, portanto fazia sentido melhorar o fluxo lá antes de tentar recriar o resultado em outro lugar. Tanto o Android quanto o iOS contam com suporte excelente a esse tipo de fluxo, oferecendo recursos especificamente para a ativação do OAuth2 por meio de janelas especializadas do navegador (Trusted Web Activity e ASWebAuthenticationSession respectivamente) que podiam ser abertas por aplicativos do celular.
Já tínhamos uma experiência de login que as pessoas conheciam do navegador, que eu gosto de chamar de "fluxo de login da web". As pessoas vinham usando esse processo havia anos, para fazer login e gerenciar contas, postar em fóruns ou efetuar inscrições. Por isso, fez sentido para nós reutilizar o mesmo modelo onde fosse possível. Passamos um bom tempo com as equipes de jogo do RuneScape e do Old School para garantir que estávamos usando os controles de segurança certos nas janelas de navegador mencionadas acima. Nosso objetivo era chegar a um mecanismo funcional
para as pessoas fazerem login usando o site em que elas já confiavam, obterem acesso ao OAuth2 e aos tokens de atualização por meio de um fluxo padronizado do authorization_code do OAuth2, e poderem fazer login no jogo pelo dispositivo móvel.
Em dezembro de 2020, pela primeira vez, as pessoas que fizeram login em um dispositivo móvel usaram o novo fluxo, compatível com as mesmas proteções que tínhamos protegendo o login no nosso site! Coisas como captcha, WAF, limitação de taxa e outras proteções-padrão disponíveis somente por meio de um navegador e chamadas de rede HTTP agora estavam protegendo o acesso a um jogo para dispositivos móveis.
O próximo truque!
Estávamos satisfeitos com o Old School em dispositivos móveis: conseguimos aprimorar e adicionar mais proteções ao acesso; tínhamos os importantíssimos logins lembrados e os outros benefícios que mencionei antes; e, quando chegou a hora de lançar RuneScape para dispositivos móveis, em 2021, a integração do fluxo do OAuth2 foi rápida e direta. A questão agora era: como transpor os mesmos benefícios para o computador?
Ao contrário do Android e do iOS, o Windows não tem uma janela de navegador que possa ser usada da mesma forma, imperceptivelmente. Em vez disso, o usuário pode ter vários navegadores que não contam com suporte direto do sistema operacional. Por isso, nós tentamos usar o navegador-padrão do usuário, de forma semelhante a como utilizamos os logins por meio da Apple e do Google no computador.
O princípio era simples:
- Clicar duas vezes no ícone da área de trabalho;
- Iniciar o cliente do jogo;
- Clicar em "Login";
- Abrir o navegador;
- Autenticar;
- Direcionar de voltar para o cliente do jogo;
- Entrar no jogo com o acesso ao OAuth2 e tokens de atualização.
No entanto, na prática, a experiência deixava muito a desejar. No fim das contas, era preciso:
- Clicar duas vezes no ícone da área de trabalho;
- Iniciar o cliente do jogo;
- Clicar em "Login";
- Abrir o navegador;
- Rezar para o navegador entrar em foco;
- Autenticar;
- Receber a mensagem sobre o login ter sido bem-sucedido;
- Fazer o usuário navegar manualmente de volta para o cliente;
- Esperar o término do processo de login;
- Obter o acesso do OAuth2 e os tokens de atualização por meio do método antigo;
- Entrar no jogo.
Começamos a procurar por passos que pudessem ser removidos. Em vez de o cliente do jogo inicializar primeiro, por que não o navegador? Com isso, em vez usar os mesmos mecanismos que os logins da Apple e do Google, buscamos uma forma de iniciar o cliente com as soluções do protocolo. Vamos ver o que acontece:
- Clicar duas vezes no ícone da área de trabalho;
- Abrir o navegador;
- Autenticar;
- Receber a mensagem de êxito;
- Receber a mensagem "Você quer mesmo abrir a mensagem deste programa?" que força os usuários a escolherem entre "sim" ou "não" ao usar funções do protocolo (alguns navegadores permitem lembrar a escolha, mas outros não. Estamos falando de você, Microsoft Edge...);
- Clicar no botão "Sim, com certeza". Se você não fizer isso, nada acontece;
- Iniciar o cliente do jogo, que agora entra em foco automaticamente graças à função do protocolo;
- Obter o acesso do OAuth2 e os tokens de atualização por meio do fluxo do authorization_code;
- Entrar no jogo.
Assim ficou mais perto do que nós queríamos. Passamos a usar o fluxo do authorization_code do OAuth2 como pretendíamos. No entanto, também passamos a ter uma mensagem de sistema horrível que não conseguíamos alterar de jeito nenhum! Além disso, se o usuário selecionasse a resposta negativa, nada acontecia e ele era forçado a começar de novo.
Além disso, e se o jogo já estivesse aberto? Seria melhor iniciar uma nova instância ou repassar a autorização para a instância existente? O RuneScape já tem uma forma de abrir o jogo a partir do navegador, é claro. No entanto, toda a filosofia do cliente do RuneScape é construída em torno de executar todas as instâncias que a pessoa quiser, em vez de manter um condutor aberto para uma única instância, tornando isso um desafio técnico complexo.
Algumas estratégias nos permitiam evitar inteiramente a mensagem:
- Fazer o cliente do jogo executar um servidor web no computador do usuário e redirecionar isso para o navegador. Com essa solução, acabaríamos na mesma situação, com o usuário tendo que mudar manualmente de volta para o cliente do jogo após a autenticação, o que nos levou a descartar a opção.
- Fazer o cliente do jogo usar o próprio navegador CEF (Chromium Embedded Framework), o que vamos discutir mais adiante.
Diversão integrada!
Se integrássemos um navegador ao pacote do jogo, isso nos daria uma interface inteiramente personalizável. Nada de mensagem ou de ter que fazer o usuário mudar manualmente entre aplicações. Quando a possibilidade surgiu, parecia ser tudo que nós queríamos, porém havia algumas ressalvas. Uma delas era específica do RuneScape, enquanto as outras advinham da perspectiva de oportunidades futuras de publicação da Jagex.
- Nós sempre nos orgulhamos de manter o cliente do jogo com um tamanho de download relativamente pequeno. Integrar algo como o CEF faria o pacote de download mais que dobrar de tamanho, algo que queríamos evitar, especialmente se fosse apenas por razões de autenticação.
- Dissemos originalmente que nosso objetivo era ter uma experiência de autenticação centralizada e unificada para o login em qualquer produto da Jagex, o que inclui jogos futuros. Portanto:
- Se integrássemos um browser ao RuneScape, estaríamos determinando que todos os jogos publicados pela Jagex usando nossos mecanismos de autorização também teriam que fazer a mesma coisa? Isso poderia ser um ponto de integração problemático, se o jogo não tivesse considerado a necessidade do CEF inicialmente.
- Um ponto fraco de ter um navegador integrado é que, com um código relativamente simples, o aplicativo de hospedagem (p. ex., o cliente do jogo) pode acessar o nome de usuário/e-mail e a senha. No caso de jogos internos, como RuneScape, não era uma grande preocupação, uma vez que a Jagex estaria em controle dos padrões de segurança, e nós podemos nos responsabilizar pela segurança dessas credenciais. Assim que esse mecanismo fosse oferecido a desenvolvedores de fora da Jagex, por meio do esquema de parcerias da Jagex, por exemplo, deixaríamos a responsabilidade pela segurança das credenciais nessa parte do fluxo por conta deles, não da nossa equipe interna. Nós não queríamos que outros estúdios tivessem que lidar com essa responsabilidade.
- Se vários jogos usassem um navegador integrado, caso uma vulnerabilidade de segurança fosse descoberta nessa tecnologia, todos os jogos teriam que ser atualizados para proteger o usuário de forma efetiva: uma tarefa hercúlea que só aumentaria à medida que jogos fossem adicionados.
- Integrar um navegador a cada cliente nos impediria de usar qualquer tipo de mecanismo simples de início de sessão em cada jogo, uma vez que eles não compartilhariam o armazenamento de tokens retornados. Em um mundo ideal, ao fazer login no RuneScape, você teria a autenticação para o Old School e para qualquer jogo publicado por nós, como Melvor Idle.
Ficou claro que, embora isso pudesse oferecer uma experiência de usuário melhor que a abordagem do navegador padrão que cogitamos antes, incorporar um navegador ao jogo não era viável a longo prazo. Nós tivemos que revisitar uma ideia antiga...
Uma ideia antiga ressurge
Perto do fim de 2020, nós estávamos prontos para discutir a possibilidade de um launcher, só que desta vez, com muito mais experiência e foco. Pegamos os mesmos conceitos que tínhamos discutido sobre um navegador integrado e os aplicamos a um launcher. Acabamos descobrindo que a solução era perfeita para os nossos casos de uso e para os nossos objetivos em termos de experiência de usuário. O launcher seria desenvolvido com um navegador integrado desde o início, para ser usado em mais do que só a autenticação e a autorização, estabelecendo a interface de usuário geral como base.
Portanto, vamos repassar os requisitos que mencionamos acima para ver como o launcher nos permite atender cada um:
- Mecanismo de autorização padrão: com o launcher contendo um navegador, o fluxo do authorization_code do OAuth2 funciona desde o primeiro momento, pois ele pode atuar como um navegador da web normal.
- Segurança e prevenção a ataques automatizados: como mencionamos antes, líderes da indústria que oferecem esses serviços fornecem software que só funciona adequadamente em um navegador, em HTTP. O launcher nos permite padronizar coisas como captchas, WAF e limitação de taxa com uma integração praticamente imperceptível.
- Logins lembrados: como também é um aplicativo nativo, o launcher é capaz de armazenar o Acesso do OAuth2 e os Tokens de Atualização com segurança no seu computador, o que torna o processo de lembrar sua sessão direto e seguro. O melhor de tudo é que qualquer título da Jagex que você jogar futuramente também contará com isso sem custo, para que nunca mais seja necessário informar as credenciais em um jogo novo. Ele simplesmente vai saber quem você é!
- Experiência de usuário transparente: como você nunca sai do launcher para informar suas credenciais, não há risco de ser preciso trocar de aplicativo manualmente, nem mensagens desagradáveis surgindo durante o processo de login.
- Download mínimo do cliente do jogo: usando o launcher para fins de autorização, os clientes dos jogos não precisam mais incorporar nenhum elemento adicional para isso, podendo manter o tamanho do download do jogo mínimo.
- Responsabilidade sobre credenciais centralizada: o launcher está, e sempre estará, sob controle da Jagex. Isso quer dizer que a Jagex será sempre responsável pela segurança do seu nome de usuário/e-mail e da sua senha, com tokens do OAuth2 passados para os jogos, independentemente de terem sido desenvolvidos interna ou externamente. Também significa que todos os nossos jogos recebem atualizações, correções e melhorias de fluxo ao mesmo tempo.
- SSO entre nossos jogos: não importa qual título da Jagex alguém esteja jogando, agora ou no futuro, o launcher sempre permitirá que ele seja aberto. Ele se torna um lugar centralizado para o armazenamento de credenciais de autorização. Se os jogadores quiserem mudar de jogo, não será preciso fazer outra autenticação.
O que esperamos que tenha ficado claro é que o launcher oferece exatamente aquilo que buscávamos, tanto do ponto de vista da experiência quanto da segurança. Claro, também há vários outros benefícios em termos de perspectiva e otimizações da experiência de usuário, mas talvez isso seja assunto para outro blog...
Para encerrar!
Espero que isso tenha ilustrado um pouco do nosso processo de desenvolvimento no que diz respeito à criação do launcher, bem como os desafios que tivemos que superar para oferecer essa ferramenta a você. O tempo todo, mantivemos a proteção da sua conta como prioridade absoluta, garantindo sempre que todas as interações com nossos jogos fossem tão transparentes quanto possível sem que a segurança fosse comprometida.
Futuramente, nosso intuito é falar mais sobre os benefícios e recursos adicionais que o launcher oferece aos jogadores e sobre como pretendemos seguir essa linha no que diz respeito à segurança e à experiência de usuário. Prepare-se para ver mais discussões em breve. Agradecemos a sua atenção!