O OpenID Connect tem uma especificação , existem tutoriais, artigos no hub e não no hub É inútil esculpir a próxima instrução passo a passo, levando de profunda perplexidade ao trabalho através de autorização e autenticação. A tarefa do texto abaixo é diferente, para descrever as idéias subjacentes às especificações (há mais de uma).
Não vou pular imediatamente o tópico do artigo, mas começarei com coisas simples e muitas óbvias. Continuarei com a maneira como eles se desenvolveram e com o que fizeram de acordo com os requisitos dos clientes. Vou abordá-lo historicamente, isto é, da mesma maneira em que ele nasceu.
1
A tarefa mínima é simplesmente não deixar ninguém acessar nenhum de seus recursos. Nós o fechamos com nome de usuário / senha, que sabe o par certo de nomes de usuário e senhas que chegarão ao recurso, quem não - não. Isso se chama autenticação , pois você pode usar não apenas logins com senhas (código SMS, por exemplo, ou uma chave USB de hardware), mas esses detalhes não são essenciais para o nosso tópico. Também omitirei o parágrafo obrigatório sobre o perigo de transmitir senhas pela Internet em um formulário aberto, para o qual todos não gostamos da autenticação de acesso básico .
Melhor observar isso: nenhum dos usuários gosta de inserir logins com senhas. Os códigos no SMS não são melhores e as chaves USB são simplesmente odiadas. Para não forçar o usuário a inserir um login com uma senha para cada solicitação, o servidor em resposta a eles envia uma linha de bobagem chamada chave de sessão . E, em seguida, essa chave se apega a cada solicitação do servidor pelo cliente (geralmente com um cabeçalho HTTP, mas isso não é essencial) e o servidor verifica se possui uma sessão desse tipo.
Sessão com uma chave - os fenômenos, por definição, são temporários, a proporção áurea para a vida útil de uma sessão é aproximadamente "enquanto a guia do navegador estiver aberta, mas não mais que um dia"
2)
Eles deixaram qualquer um entrar - isso é bom. Agora você precisa entender exatamente quem deixamos de lado. E não apenas para deduzir o que ele inseriu como nome no canto superior direito, mas também para decidir o que deixar entrar e o que não.
E tudo isso é chamado - autorização . E não tenho certeza sobre você, mas confundo com autenticação o tempo todo. Para não confundir - uma regra relativamente mnemônica, "autorização" - das palavras "autor", "autor", eles escrevem nas capas dos livros e nunca escrevem lá "um membro válido da União dos Escritores". Um autor é sempre uma pessoa muito específica. Portanto, a autorização é um processo quando entendemos exatamente quem lançamos por login e senha.
3)
Ok Temos um site, há algo secreto no site, na entrada da parte secreta, exigimos uma senha, cada um é mostrado apenas seus segredos e não mostramos estranhos. A vida não pára e temos outro site. E aqui novamente encontramos o problema do ponto 1, ninguém gosta de inserir nomes de usuário e senhas! Você pode combinar a base de usuários e isso evita que eles precisem se registrar duas vezes, mas como evitar que reinsira o login e a senha na entrada? Dada a existência de uma política de mesma origem (e nossos sites estão localizados, é claro, em domínios diferentes, os cookies com uma chave de sessão não são visíveis um para o outro)? Aqui, para dar importância ao momento, começarei um novo ponto.
4)
SSO , Logon único - qualquer que seja a implementação, Microsoft Kerberos, SAML ou algo OAuth 2.0 , sobre o qual o OpenID Connect é construído, sobre o qual estou escrevendo aqui, na verdade, sempre há a mesma coisa: existe um servidor separado autorização e qualquer pessoa que queira autorizar um usuário o redireciona para ele. Se o usuário já estiver autorizado, a sessão será selecionada e ele imediatamente retornará do servidor de autorização e chegará ao local desejado. Se não estiver autorizado, o servidor de autorização resolverá o problema da melhor maneira possível, solicitando um nome de usuário com uma senha, em regra, e se for bem-sucedido, envia o usuário de volta.
Além disso, o SAML no momento em que a solução está desatualizada. E o Kerberos geralmente é uma mágica fechada da Microsoft, completamente separada, que vai muito além do escopo do protocolo HTTP. Bem, vamos nos concentrar nisso. E então chegamos ao próximo problema.
Já existe um cenário de trabalho compreensível - em qualquer situação incompreensível, envie o usuário ao servidor de autorização, deixe que ele decida o que fazer com ele e retorne uma resposta pronta. Mas como exatamente o servidor de autorização diz ao outro servidor que o usuário está autorizado? Aqui voltamos novamente às idéias do primeiro parágrafo, a saber, à chave da sessão. Vamos voltar ao básico: a presença de uma chave de sessão é um sinal de autorização, a própria chave de sessão abre a porta para as informações do usuário e, você não acreditará, para as informações da sessão. Portanto, o servidor de autorização autoriza e fornece a chave da sessão para outro servidor.
Agora, no entanto, não é mais chamada de chave da sessão, mas de um token .
Mais precisamente, (de acordo com o protocolo OAuth 2.0 , sobre o qual o OpenID Connect é gravado), esses são dois tokens de uma só vez - Token de Acesso , para conectá-lo a todas as solicitações como chaves de sessão cortadas pelos avós e Atualizar Token , para atualizar o Token de Acesso quando ele sair.
Para resumir o subtotal. Em vez de solicitar ao usuário um nome de usuário e senha, o servidor envia para outro servidor, um servidor de autorização separado. Ele faz todo o trabalho e depois fornece os primeiros tokens. Exatamente nesse cenário, os aplicativos são autorizados, móveis e, às vezes, para área de trabalho.Eles não fazem redirecionamentos, apenas enviam o servidor de autorização JSON com um nome de usuário e senha e ele envia tokens em resposta.
Aplicativos móveis e de desktop podem fazer isso. Por alguma razão, eles são considerados mais seguros que a web, mas a web tem uma vida mais complicada.
6
Por um lado, não é mais complicado, mas, pelo contrário, mais simples. Você pode fazer um redirecionamento e não se incomodar em renderizar um formulário de senha de login. Por outro lado, eu realmente não quero arrastar tokens pelo navegador de forma clara. Isso é quase tão nojento quanto a senha não criptografada na autenticação de acesso básico . Mas ninguém quer repetir esse velho e terrível erro.
Não houve solução para o problema, de modo que ele é muito elegante, mas está funcionando. Primeiro, tudo corre como sempre, alternando para autorização, a própria autorização. Então, quando chegar a hora de voltar com tokens, o redirecionamento reverso ocorrerá. Mas, em vez de tokens, um código único é anexado ao endereço de retorno. O código único acabou de ser gerado pelo servidor de autorização apenas para esse momento específico. Ele tem um tempo de vida muito curto. Tendo recebido apenas um código único, outro servidor deve abrir as saias, arregalar os olhos e correr novamente para o servidor de autorização, a fim de receber os tokens cobiçados do código único.
Há um recurso especial para uma viagem com um código para tokens no servidor de autorização. Ele aceita, por especificação, não GET, mas POST. De alguma forma, isso nos indica que essa solicitação não deve ser feita pelo navegador, mas de servidor para servidor.
Pelo mesmo motivo, em qualquer servidor de autorização CORS que se preze, as solicitações POST são proibidas.
7)
A propósito, você ainda se lembra da autenticação e autorização? Autenticação é quando alguém simplesmente tem permissão para entrar por login e senha, ou não é permitido. E a autorização é que, quando eles já começaram, eles começam a entender quem exatamente eles começaram.
Você se lembra do OAuth 2.0 ? Eu mencionei isso algumas vezes acima, como algum tipo de base para o OpenID Connect.
Você se lembra do OpenID Connect ? Este artigo é apenas ele burro.
Portanto, o OAuth 2.0 é autenticação. Todo o procedimento descrito anteriormente um pouco confuso com três participantes, uma senha, um código e um token tem tudo a ver com autenticação, apenas sobre deixar alguém correr em algum lugar. Protocolo OAuth 2.0.
OpenID Connect é autorização. Ou seja, ele adiciona ao OAuth aquelas partes em que acontece quem eles soltam.
Para fazer isso, mais um é adicionado à lista de tokens, chamada de Token de ID . Aqueles que seguem o link provavelmente ficam surpresos ao não verem nada sobre qualquer ID de Token nele. Que a surpresa não se assuste, esse ID do token é o JWT retornado como uma boneca aninhada codificada em base64 no mesmo JSON que o token de acesso e o token de atualização. De qualquer forma, tudo o que você queria saber sobre o usuário está nele.
E também há um recurso especial no servidor de autorização chamado userinfo, no qual você pode bater com o Access Token e obter o mesmo JSON em resposta que no Token ID. Mas por que é necessário se o Token ID já está lá? Pergunta aos autores das especificações.
O OpenID Connect também contém uma descrição dos vários campos de informações do usuário. Como posso obter essas informações, durante a autorização ou a qualquer momento depois. E uma descrição de como e quando o usuário permitirá que você use essas informações.
Ou não permitir. Portanto, em resumo, o OpenID Connect 1.0 foi projetado.
8)
Um pequeno enfeites no protocolo. Espero que você esteja cansado o suficiente de ler o artigo no momento, para não prestar muita atenção a este item, apenas passando-o pelos olhos. Aqui, mencionarei os parâmetros que estão na especificação e eles carregam alguma carga semântica, mas não estão diretamente relacionados à implementação da ideia em si. Basicamente, eles adicionam segurança, ou simplesmente permitem que você transfira algumas informações de um dos participantes do processo para outro, se necessário.
ID do cliente e segredo do cliente . O cliente no idioma do protocolo OpenID Connect não é um navegador, mas o outro servidor que precisa autorizar o usuário. Suponha que você tenha um site e queira anexar uma autorização de moda a ele via Facebook. E através do googol. E não tão na moda via Twitter. A implementação do protocolo no código não será suficiente. Você também precisará se registrar no Facebook, no Google e no Twitter, mas não como usuário, mas como o próprio cliente que, como servidor, pode usar sua autorização. Ao se registrar, você receberá um ID do cliente e um Segredo do cliente do facebook condicional. E ao solicitar autorização, entre outras coisas, envie um ID do cliente. E quando você usa um código único para um token, o Client Secret também exige.
Redirecionar URI . Tudo é simples aqui. Ao enviar um usuário a um facebook condicional para efetuar login, você precisa informar ao Facebook onde devolver códigos e tokens para ele após a autorização. Claro, você ainda dá a ele seu Client ID. Mas um URI de redirecionamento separado permite redirecionar após a autorização usuários diferentes para páginas diferentes, por exemplo, administradores do painel de administração e usuários comuns para suas páginas pessoais. Prático. Além disso, a lista permitida de possíveis URIs de redirecionamento especificados nas configurações do cliente no facebook condicional é uma segurança adicional.
Âmbito . Esta é uma lista do que o servidor deseja saber sobre o usuário no servidor de autorização. Os valores na lista são separados por espaços, openid deve ser obrigatório entre eles e, em seguida, leia a especificação.
Estado . Lembra-se do código único, pelo qual os tokens são emitidos, como um ticket em uma fila eletrônica? Portanto, state é código, pelo contrário, se o servidor de autorização emitir um código para outro servidor para que ele o retorne em breve, esse estado fornecerá outro servidor de autorização para esse servidor para devolvê-lo durante o redirecionamento. Ele é necessário, pelo que entendi, se outro servidor já conseguiu criar sua própria sessão para que não se perca em todos esses redirecionamentos.
Existem outros parâmetros, como o tipo de solicitação de autorização e a vida útil do token, mas para entender por que você não precisa deles.
Em conclusão. Eu realmente espero que a leitura não muito cuidadosa e focada do texto acima em algum lugar tenha ajudado a capturar as idéias subjacentes a alguns protocolos modernos de controle de acesso. Mas, ao começar a implementar, ou apenas configurar um deles, abra as especificações, encontre um bom tutorial e siga cuidadosamente cada palavra e letra. E deixe a compreensão das idéias despertar intuição em você. E intuição, deixe-o morder a coroa toda vez que você perder um parâmetro que não é tão significativo à primeira vista, ou um cenário, e deixe isso como um buraco para pequenas mãos suadas e brincalhonas.
Lembre-se de que tudo isso é a mesma segurança, e suas regras, não importa quão estúpidas e sem sentido possam parecer, estão escritas em sangue. Bem, talvez não com sangue, afinal de contas, não é uma medida de segurança na fundição, mas dinheiro e reputação são certos, e dinheiro e reputação também não são coisas que você deve facilmente jogar dessa maneira.
Agradeço a JM pelo fato de o texto que você leu ser muito melhor do que o que escrevi.
Boa sorte e não se esqueça de renovar seus certificados a tempo.