Gestão de reivindicações
P>Próximo, precisamos de pensar cuidadosamente nas reivindicações. Uma reivindicação é simplesmente o par nome/valor incorporado nos nossos Tokens de Acesso e de Identificação. Por exemplo, poderá ter um user_id ou uma reclamação por e-mail para que as aplicações a jusante possam utilizá-los para criar perfis ou tomar decisões. A parte confusa é que a especificação do OAuth Core não introduz o conceito de reivindicações ou mesmo inclui a palavra reivindicação. Isto é útil porque podemos definir o que for preciso. Infelizmente, o desafio é que as pessoas as definirão da forma que precisarem. A especificação JWT (RFC 7519) introduz o conceito e define uma estrutura básica mas ainda não define nenhuma convenção para nomes, estruturas, etc.
Utilizar OpenID Connect protege-nos bastante. Define um conjunto simples de reivindicações para detalhes do utilizador, tais como nome, endereço, e similares. Se apenas as utilizarmos e limitarmos o acesso de acordo com os âmbitos apropriados, o utilizador sabe que informação está a partilhar e as aplicações sabem como utilizá-la.
Alternativamente, à medida que adicionamos reivindicações adicionais, o desejo natural é ter um identificador único de utilizador. Se pensarmos bem, utilizamos uma chave primária ofuscada que não tem qualquer significado fora do nosso sistema. Se não tivermos cuidado, isso poderá ser um identificador de cliente, número de funcionário, ou mesmo um número de Segurança Social. Esta é a mesma situação em que o Facebook se debate com as implicações de partilhar demasiada informação sobre a rede de um utilizador através da sua API.
Temos de ser atenciosos e considerar as consequências da informação que colocamos nas nossas fichas. Nunca devemos incluir dados “por precaução” e, em vez disso, esperar por casos específicos de utilização que escolhemos apoiar. Qualquer outra coisa é arriscada na melhor das hipóteses e irresponsável na pior.
Tipos de subvenção – Quando e Porquê
Enquanto eu saltei directamente para os âmbitos e reivindicações, o outro erro mais comum está relacionado com os tipos ou fluxos específicos de subvenções OAuth. Os quatro tipos de concessão – Código de Autorização, Implícito, Senha do Proprietário do Recurso e Credencial do Cliente – definem como uma aplicação pode recuperar fichas do seu servidor OAuth e são utilizadas em diferentes casos de utilização.
Código de Autorização
O fluxo do Código de Autorização é o mais poderoso e o mais seguro por defeito. Quando a aplicação redirecciona o utilizador para o Provedor de Identidade para autenticar, o IdP passa de volta um código de autorização de uso único e de curta duração. A aplicação utiliza o código de autorização para recuperar o Token de Acesso.
A parte importante é dupla: Primeiro, quando o utilizador vê o código de autorização, este já foi consumido e, portanto, não pode ser utilizado novamente. Segundo, o Token de Acesso é guardado pela aplicação no backend. Assumindo que a aplicação é construída com segurança, um utilizador malicioso tem de encontrar outra forma de a atacar.
Felizmente, isto não funciona para aplicações do lado do cliente, tais como muitas aplicações Javascript ou a maioria das aplicações móveis, uma vez que a própria aplicação pode ser atacada ou descompilada para informação sensível. Portanto, precisamos de uma abordagem diferente.
Implicit
O fluxo implícito é concebido especificamente para aplicações móveis ou aplicações Javascript do lado do cliente onde as credenciais incorporadas poderiam ser comprometidas. A mecânica é simples na medida em que a aplicação redirecciona o utilizador para o Fornecedor de Identidade para autenticar, o IdP passa de volta o(s) token(s), e a aplicação usa-o de acordo com os âmbitos que tem.
P>Posto ser bastante provável que o utilizador possa interagir com o(s) token(s), é importante que os nossos casos de utilização reflictam isso. Se tivermos uma aplicação bancária, permitir o âmbito send_wire_transfers_to_russia pode ser uma má ideia, a menos que tenhamos factores adicionais cozinhados no nosso processo de autenticação para validar que o utilizador certo está a utilizá-lo. Da próxima vez que perder o seu telefone, irá apreciar isso.
Como resultado, isto é frequentemente utilizado para cenários OpenID Connect em que um utilizador quer fornecer informação de perfil de confiança a terceiros, mas não necessariamente acesso ou permissões a outros sistemas. Uma vez que os conceitos subjacentes são os mesmos e a implementação parece muito semelhante, é a maior parte do benefício pelo mesmo esforço.
Senha do Proprietário de Recursos
Em comparação com os tipos de concessões anteriores, a Senha do Proprietário de Recursos deixa-me nervoso. Tanto com o Código de Autorização como com fluxos Implícitos, a aplicação redirecciona o utilizador para o Provedor de Identidade para submeter o seu nome de utilizador e palavra-passe. Como resultado, o pedido nunca vê as suas credenciais. Com o fluxo de Senha do Proprietário do Recurso, a própria aplicação aceita as credenciais e submete-as em nome do utilizador.
Se a aplicação for maliciosa ou mesmo mal desenvolvida, poderá armazenar essas credenciais e comprometer a informação do utilizador. Por conseguinte, só deve utilizá-la se estiver a construir aplicações para os seus utilizadores interagirem com os seus sistemas herdados. Por exemplo, um banco pode implementá-la para um portal interno de funcionários.
Mas lembre-se: Fundamentalmente, está a formar os utilizadores para colocar as suas credenciais em aplicações em que podem não confiar, o que é um mau hábito na melhor das hipóteses e um risco de segurança a todo o momento.
Credencial de Cliente
O tipo de concessão de Credencial de Cliente é concebido exclusivamente para operações backend de servidor para servidor. Pense nisso como um nome de utilizador e senha de um servidor. Conceptualmente, não está longe de como a sua aplicação se liga a outros sistemas backend, tais como a sua base de dados ou Twilio. O benefício é que o seu fornecedor OAuth pode devolver informações de configuração ou outros detalhes dentro do próprio token.
Finalmente, uma vez que não há um utilizador envolvido, não suporta OpenID Connect.
Em Encerramento
Embora todo este post tenha sido sobre OAuth, já deve ter reparado que não incluí nenhum código. A razão para isso é simples: As decisões de concepção são ainda mais importantes.
Se os seus âmbitos forem demasiado amplos ou se as suas reivindicações incluírem informação sensível ou se implementar o fluxo errado para o ambiente, as melhores bibliotecas do mundo não o protegerão. A informação dos seus utilizadores será comprometida, as suas aplicações serão vulneráveis, e a sua empresa sofrerá as consequências. Alternativamente, se compreender os casos de utilização do seu software e o que os seus utilizadores estão a tentar realizar, o seu software será melhor, mais seguro, e poderá limitar os e-mails “Pedimos desculpa…” aos seus clientes.
Para Leituras Adicionais
Daqui podemos continuar a entrar nos protocolos, bibliotecas individuais, ou grandes livros sobre o assunto. Se quiser compreender como os RFCs individuais se encaixam, consulte o livro de Aaron Parecki OAuth2.0 Simplificado e o Mapa de OAuth 2.0 Specs que o acompanha. É a minha folha de cheatsheet em links para as especificações-chave e qual delas cobre o quê. Todos estes elementos inspiraram o meu guia de Práticas Recomendadas para Gestão de Acesso API que detalha bons princípios de design e desenvolvimento para Clientes OAuth, Servidores de Autorização, gateways API, e as suas aplicações.