Protocolos OIDC x SAML. Por que adotamos OIDC?
Durante muitos anos a RD Station armazenou as informações do usuário para controle de sessão, login/logout e recuperação de senha no Auth0, uma plataforma terceira que oferece todo o processo de autenticação e autorização de usuários. Quando a organização, no final de 2020, passou a olhar mais profundamente para esse domínio, identificou-se a necessidade de um time ser responsável por ele. Assim, nasceu o time Accounts Auth, também conhecido carinhosamente como Gandauth.
Essa equipe tem como uma de suas responsabilidades fornecer a estrutura necessária para identificação, autenticação e autorização, tanto para usuários finais (nossos clientes) quanto para pessoas desenvolvedoras de aplicativos terceiros que desejam se conectar ao ecossistema da RD Station.
No final de 2019, nos encontramos em uma situação em que o modelo de custo do Auth0 não era mais compatível com a taxa de crescimento da RD. O custo com autenticação era o 3o maior ofensor do COGS (Cost of Good Sold). A primeira grande missão do time Gandauth foi buscar alternativas para esse problema. Com isso, identificamos a oportunidade de reduzir o valor investido no nosso Identity Provider (Auth0), fazendo o movimento de migração para o serviços oferecidos pela nossa parceira Google: Identity Platform. Para fazer o movimento de migração, decidimos manter os dois provedores de identidade sincronizados, ou seja, o Auth0 e o Identity Platform. Essa estratégia foi necessária visto que ainda possuímos aplicações terceiras conectadas ao Auth0 (por exemplo: nossa Central de Ajuda e Portal de Parceiros), ou seja, através do legado continuamos a oferecer suporte a essas aplicações. Conseguimos migrar 95,74% dos usuários do Auth0 para o Identity Platform, porém ainda tínhamos 4,26% dos usuários logando via aplicações terceiras.
Em paralelo à saída do Auth0, ocorre a migração da nossa central de ajuda atualmente conectada ao Auth0 para o Salesforce. Com isso, aproveitamos da necessidade dessa migração para adotar um protocolo de autenticação que forneça um mecanismo seguro para o usuário e já faça as consultas na nossa base do Identity Platform, sem interações com o Auth0.
Para ficar mais claro, é importante diferenciarmos os conceitos de autenticação e autorização:
- Autenticação: é a validação da identidade do usuário, basicamente é verificado se ele é quem ele diz ser. Um exemplo é informar email e senha para acessar um sistema, usufruir de uma única sessão ou login único para outras plataformas.
- Autorização: se trata das permissões que o usuário fornece a uma ferramenta terceira para acessar recursos da sua conta. Com a aprovação do usuário, o protocolo de autorização faz troca de tokens, sem precisar acessar suas credenciais. Você geralmente faz isso quando está permitindo que uma plataforma (como o Facebook) acesse determinadas informações da sua conta Google.
Para fornecer uma maneira segura de autenticação, identificamos duas opções de protocolos a serem adotadas: OIDC (OpenID Connect) ou SAML (Security Assertion Markup Language). Estes são protocolos de identidade (Identity Protocol), que autenticam o usuário, provêm dados de identidade para controle de acesso e atuam como um meio de comunicação segura para a transferência de dados do usuário (por exemplo, location) entre um provedor de identidade e o serviço terceiro (no nosso caso o Salesforce).
Para tomar a decisão sobre qual protocolo seria adotado na etapa de autenticação entre o serviço terceiro e o provedor de identidade, fizemos estudos e comparações sobre os protocolos SAML e OIDC. Em um primeiro momento, procuramos diferenciar as características técnicas (por exemplo, segurança) e dificuldades de desenvolvimento (aqui incluímos o provisionamento da infraestrutura, codificação, curva de aprendizado por parte das pessoas desenvolvedoras e documentação). As diferenças técnicas que nos auxiliaram na decisão estão listadas abaixo:
Levando em consideração as características técnicas citadas e o trabalho já realizado pelo time em relação à segurança, o OIDC já demonstra-se mais atrativo visto que HTTPS nos fornece mais segurança. Além disso, hoje não fornecemos experiência mobile ao acessar o produto RD Station Marketing, porém oferecemos ao RD Station CRM, nossa plataforma de gestão de relacionamento com o cliente e vendas.
Outro ponto levado em consideração é que, usufruindo das funcionalidades fornecidas pelo OAuth2, podemos reduzir complexidade no nosso código visto que hoje possuímos um domínio conhecido como Ecosystems, que é responsável por fornecer integração de parceiros à nossa ferramenta, ou seja, esses parceiros precisam passar pela etapa de autorização.
Dado que estávamos inclinados a adotar OIDC, tínhamos uma última decisão para tomar: comprar uma solução de mercado ou utilizar uma solução Open-Source de Provedor OpenID Connect. Optamos por seguir com um projeto open source, o ory-hydra. Levamos em consideração diversos fatores para decidir por qual caminho seguir. Além dos tópicos citados na tabela e levando em conta que um dos nossos objetivos é desenvolver o mínimo possível de funcionalidades in-house, identificamos que o protocolo OIDC atenderia nossas necessidades e as de nossos clientes neste momento. Seguir com OIDC via ory-hydra foi o melhor caminho para nós. Ele já está em fase de testes por parte do nosso time e falaremos mais sobre ele nos próximos posts.
Caso você tenha gostado desse desafio e tenha interesse em trabalhar com desenvolvimento de alto impacto, conheça as nossas vagas disponíveis ❤
