Grant Type Implicit no OAuth 2.0
O Grant Type Implicit, tambem conhecido como metodo "token", foi primariamente concebido para aplicacoes do lado do cliente onde o cliente nao consegue armazenar de forma segura um client secret. Tais aplicacoes incluem aplicacoes de pagina unica (SPAs) ou outras aplicacoes baseadas em navegador. Em vez de receber um codigo de autorizacao que precisa de ser trocado por um token de acesso, a aplicacao obtem o token de acesso diretamente.
Como Funciona o Grant Type Implicit?
- Redirecionamento:
- A aplicacao cliente redireciona o utilizador para o endpoint de autorizacao do servidor de autorizacao OAuth 2.0. Este redirecionamento geralmente inclui parametros de consulta como
client_id,response_type(definido como "token" para o Grant Implicit),redirect_uri(para onde o servidor de autorizacao redirecionara apos conceder/negar acesso) escope(indicando o nivel de acesso solicitado).
- Autenticacao do Utilizador:
- O utilizador faz login no servidor de autorizacao (se ainda nao tiver sessao iniciada) e revisa o pedido de acesso pela aplicacao cliente.
- Emissao do Token de Acesso:
- Se o utilizador conceder o acesso, o servidor de autorizacao redireciona-o de volta para a aplicacao cliente atraves do
redirect_urifornecido. O URI de redirecionamento inclui o token de acesso (e a sua expiracao) diretamente na parte de fragmento do URL.
- Aceder ao Recurso Protegido:
- A aplicacao cliente extrai o token de acesso do fragmento do URL e armazena-o (por exemplo, em armazenamento local ou sessao). Depois usa este token para fazer pedidos ao servidor de recursos (API) em nome do utilizador.
Como Configurar o Grant Type Implicit?
- Registar a Sua Aplicacao:
- Comece por registar a sua aplicacao com o fornecedor OAuth 2.0. Tipicamente recebera um
client_idapos registo bem-sucedido.
- Configuracao do Redirect URI:
- Forneca um
redirect_uridurante o registo. O servidor de autorizacao redirecionara os utilizadores para este URI apos decidirem sobre conceder ou negar acesso. Garanta que este URI e seguro (tipicamente usando HTTPS) e consegue tratar a extracao de token do fragmento do URL.
- Iniciar o Fluxo OAuth:
- Redirecione os utilizadores para o endpoint de autorizacao do servidor de autorizacao com os parametros necessarios. Use bibliotecas ou SDKs adequados a linguagem ou framework da sua aplicacao para facilitar isto.
- Extrair e Armazenar o Token:
- Uma vez redirecionado de volta, extraia o token de acesso do fragmento do URL. Armazene o token de forma segura, considerando opcoes de armazenamento do lado do cliente como Web Storage (localStorage ou sessionStorage) ou cookies. Garanta que esta protegido contra ataques de cross-site scripting (XSS).
- Usar o Token:
- Anexe o token de acesso aos pedidos API feitos ao servidor de recursos.
- Lidar com Expiracao de Token:
- Uma vez que o Grant Implicit geralmente nao fornece refresh tokens, quando um token de acesso expira, pode precisar de iniciar o fluxo OAuth novamente para obter um novo.
Consideracoes:
Seguranca: O Grant Type Implicit e considerado menos seguro que o Grant Type Authorization Code, especialmente porque o token de acesso e exposto no URL. Isto pode ser um risco em ambientes onde os URLs podem ser registados ou acedidos por terceiros.
Sem Refresh Token: Tipicamente, o Grant Implicit nao fornece refresh tokens. Portanto, quando um token de acesso expira, todo o fluxo pode precisar de ser repetido.
Descontinuacao: Devido as suas preocupacoes inerentes de seguranca, o documento de Melhores Praticas de Seguranca OAuth 2.0 recomenda evitar o Grant Implicit em favor do Authorization Code com PKCE (Proof Key for Code Exchange) para clientes publicos, como SPAs.
Conclusao:
Embora o Grant Type Implicit ofereca um fluxo mais simples para aplicacoes do lado do cliente, as suas preocupacoes de seguranca levaram a recomendacoes contra a sua utilizacao em aplicacoes modernas. Se esta a construir novas aplicacoes, especialmente SPAs, considere usar o Grant Authorization Code com PKCE para uma abordagem mais segura.