oauth

O refresh token é um token de referência, portanto, você pode revogá-lo se alguém o roubar. Como token de referência, o protocolo o define como de longa duração. Se você removê-lo do armazenamento do Servidor de Autorização, o invasor não poderá obter um novo token de acesso novamente. O Servidor de Autorização pode fornecer uma lista de aplicativos aprovados pelo usuário (e que podem ser revogados). O caso de uso usual é a sessão de duração (renovar o token de acesso obtendo um novo sem fornecer as credenciais novamente)....

Quando há um problema de autorização, existem 2 códigos de status de resposta HTTP usados para informar o cliente um pouco mais sobre o problema: 401 - Não Autorizado O Servidor de Recursos pode responder para um dos 2 cenários: Não sabemos quem você é Não aceitaremos mais seu token porque ele expirou 403 - Proibido O Servidor de Recursos responde para o cenário: Sabemos perfeitamente que você é mas, você não tem permissão para acessar este recurso

Para o OAuth 2.1, a quantidade de fluxos recomendados diminuiu (de 5 para 2), sendo eles: Credenciais do Cliente Código de Autorização com PKCE Credenciais do Cliente Esse fluxo representa a comunicação máquina a máquina, na qual você não tem um usuário “interativo” presente ou, pelo menos, não se importa com isso. Isso significa que as informações do usuário não são necessárias para obter acesso aos recursos, apenas as informações do cliente....

No ano de 2005 surgiu o primeiro protocolo utilizando tecnologias web para fornecer autenticação e autorização com provedor de identidade: SAML 2.0. Antes era possível fazer isso em aplicações web com tecnologias NTLM ou Kerberos colocando-as dentro do navegador para ter acesso aos recursos usando o Active Directory, por exemplo, como forma de ter single sign-on nessas aplicações. No entanto, a ideia com o SAML 2.0 era sobre como poderíamos provar que o usuário é o usuário fazendo requisições pelo navegador?...