"use strict"; const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0]; const {useMDXComponents: _provideComponents} = arguments[0]; const headings = [{ "data": { "id": "introdução", "hProperties": { "id": "introdução" } }, "depth": 2, "value": "Introdução" }, { "data": { "id": "oauth-20-vs-openid-connect", "hProperties": { "id": "oauth-20-vs-openid-connect" } }, "depth": 2, "value": "OAuth 2.0 vs. OpenID Connect" }, { "data": { "id": "oauth-20", "hProperties": { "id": "oauth-20" } }, "depth": 3, "value": "OAuth 2.0" }, { "data": { "id": "openid-connect-oidc", "hProperties": { "id": "openid-connect-oidc" } }, "depth": 3, "value": "OpenID Connect (OIDC)" }, { "data": { "id": "tipos-de-aplicação", "hProperties": { "id": "tipos-de-aplicação" } }, "depth": 2, "value": "Tipos de aplicação" }, { "data": { "id": "aplicações-web-a-correr-num-servidor", "hProperties": { "id": "aplicações-web-a-correr-num-servidor" } }, "depth": 3, "value": "Aplicações web a correr num servidor" }, { "data": { "id": "aplicações-de-página-única-spas", "hProperties": { "id": "aplicações-de-página-única-spas" } }, "depth": 3, "value": "Aplicações de página única (SPAs)" }, { "data": { "id": "aplicações-móveis", "hProperties": { "id": "aplicações-móveis" } }, "depth": 3, "value": "Aplicações móveis" }, { "data": { "id": "aplicações-de-máquina-para-máquina-m2m", "hProperties": { "id": "aplicações-de-máquina-para-máquina-m2m" } }, "depth": 3, "value": "Aplicações de máquina-para-máquina (M2M)" }, { "data": { "id": "aplicações-a-correr-em-dispositivos-iot", "hProperties": { "id": "aplicações-a-correr-em-dispositivos-iot" } }, "depth": 3, "value": "Aplicações a correr em dispositivos IoT" }, { "data": { "id": "protege-a-tua-api", "hProperties": { "id": "protege-a-tua-api" } }, "depth": 2, "value": "Protege a tua API" }, { "data": { "id": "design-de-autorização", "hProperties": { "id": "design-de-autorização" } }, "depth": 3, "value": "Design de autorização" }, { "data": { "id": "tokens-de-acesso", "hProperties": { "id": "tokens-de-acesso" } }, "depth": 3, "value": "Tokens de acesso" }, { "data": { "id": "indicadores-de-recursos", "hProperties": { "id": "indicadores-de-recursos" } }, "depth": 3, "value": "Indicadores de recursos" }, { "data": { "id": "juntando-tudo", "hProperties": { "id": "juntando-tudo" } }, "depth": 2, "value": "Juntando tudo" }, { "data": { "id": "notas-finais", "hProperties": { "id": "notas-finais" } }, "depth": 2, "value": "Notas finais" }]; const readingTime = { "minutes": 13, "words": 3922, "text": "13 min read" }; const frontmatter = undefined; function _createMdxContent(props) { const _components = { a: "a", blockquote: "blockquote", code: "code", h2: "h2", h3: "h3", li: "li", ol: "ol", p: "p", pre: "pre", span: "span", strong: "strong", ul: "ul", ..._provideComponents(), ...props.components }, {LogtoCloudButton} = _components; if (!LogtoCloudButton) _missingMdxReference("LogtoCloudButton", true); return _jsxs(_Fragment, { children: [_jsxs(_components.h2, { id: "introdução", children: ["Introdução", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#introdução", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "As aplicações em nuvem são a tendência hoje em dia. Embora o tipo de aplicação varie (web, móvel, desktop, etc.), todas têm um backend em nuvem que fornece serviços como armazenamento, computação e bases de dados. Na maioria das vezes, estas aplicações precisam de autenticar utilizadores e autorizá-los a aceder a determinados recursos." }), "\n", _jsx(_components.p, { children: "Embora seja possível criar mecanismos de autenticação e autorização próprios, a segurança tornou-se uma das principais preocupações ao desenvolver aplicações em nuvem. Felizmente, a nossa indústria tem padrões testados em batalha como OAuth 2.0 e OpenID Connect para nos ajudar a implementar autenticação e autorização seguras." }), "\n", _jsx(_components.p, { children: "Este post tem as seguintes suposições:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Tens um entendimento básico de desenvolvimento de aplicações (web, móvel, ou qualquer outro tipo)." }), "\n", _jsx(_components.li, { children: "Já ouviste falar dos conceitos de autenticação e autorização." }), "\n", _jsxs(_components.li, { children: ["Já ouviste falar de ", _jsx(_components.a, { href: "https://auth.wiki/oauth-2.0", children: "OAuth 2.0" }), " e ", _jsx(_components.a, { href: "https://auth.wiki/openid-connect", children: "OpenID Connect" }), "."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Sim, \"ouvir falar\" é suficiente para o 2 e o 3. Este post usará exemplos do mundo real para explicar conceitos e ilustrar o processo com diagramas. Vamos começar!" }), "\n", _jsxs(_components.h2, { id: "oauth-20-vs-openid-connect", children: ["OAuth 2.0 vs. OpenID Connect", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#oauth-20-vs-openid-connect", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Se estiveres familiarizado com OAuth 2.0 e OpenID Connect, podes continuar a ler porque cobriremos alguns exemplos do mundo real nesta seção; se fores novo nestes padrões, também é seguro continuar, pois iremos introduzi-los de uma forma simples." }), "\n", _jsxs(_components.h3, { id: "oauth-20", children: ["OAuth 2.0", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#oauth-20", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: [_jsx(_components.a, { href: "https://auth.wiki/oauth-2.0", children: "OAuth 2.0" }), " é uma estrutura de autorização que permite a uma aplicação obter acesso limitado a recursos protegidos em outra aplicação em nome de um utilizador ou da própria aplicação. A maioria dos serviços populares como Google, Facebook e GitHub usa OAuth 2.0 para login social (por exemplo, \"Entrar com Google\")."] }), "\n", _jsx(_components.p, { children: "Por exemplo, tens uma aplicação web MyApp que quer aceder ao Google Drive do utilizador. Em vez de pedir ao utilizador para partilhar as suas credenciais do Google Drive, a MyApp pode usar OAuth 2.0 para solicitar acesso ao Google Drive em nome do utilizador. Aqui está um fluxo simplificado:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant Google\n\n User->>MyApp: Abrir MyApp e
clicar \"Conectar Google Drive\"\n MyApp->>Google: Redirecionar para o Google\n Google->>User: Entrar no Google\n User->>Google: Entrar\n Google->>User: Pedir permissão
para acessar o Google Drive\n User->>Google: Conceder acesso à MyApp\n Google->>MyApp: Redirecionar para a MyApp
com dados de autorização (por ex., token de acesso)\n MyApp->>Google: Acessar o Google Drive do utilizador\n" }) }), "\n", _jsxs(_components.p, { children: ["Neste fluxo, a MyApp nunca vê as credenciais do Google Drive do utilizador. Em vez disso, recebe um ", _jsx(_components.a, { href: "https://auth.wiki/access-token", children: "token de acesso" }), " do Google que lhe permite acessar o Google Drive em nome do utilizador."] }), "\n", _jsxs(_components.p, { children: ["Nos termos do OAuth 2.0, a MyApp é o ", _jsx(_components.a, { href: "https://auth.wiki/client", children: "client" }), ", o Google é tanto o ", _jsx(_components.a, { href: "https://auth.wiki/authorization-server", children: "servidor de autorização" }), " quanto o ", _jsx(_components.a, { href: "https://auth.wiki/resource-server", children: "servidor de recursos" }), " para simplificar. No mundo real, muitas vezes temos servidores de autorização e de recursos separados para oferecer uma experiência de single sign-on (SSO). Por exemplo, o Google é o servidor de autorização e pode ter vários servidores de recursos como Google Drive, Gmail e YouTube."] }), "\n", _jsx(_components.p, { children: "Note que o fluxo de autorização real é mais complexo do que isso. O OAuth 2.0 tem diferentes tipos de concessão, âmbitos e outros conceitos que deves estar ciente. Vamos deixar isso de lado por agora e passar para o OpenID Connect." }), "\n", _jsxs(_components.h3, { id: "openid-connect-oidc", children: ["OpenID Connect (OIDC)", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#openid-connect-oidc", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["OAuth 2.0 é ótimo para autorização, mas podes notar que não tem uma maneira de identificar o utilizador (ou seja, autenticação). ", _jsx(_components.a, { href: "https://auth.wiki/openid-connect", children: "OpenID Connect" }), " é uma camada de identidade em cima do OAuth 2.0 que adiciona capacidades de autenticação."] }), "\n", _jsx(_components.p, { children: "No exemplo acima, a MyApp precisa saber quem é o utilizador antes de iniciar o fluxo de autorização. Note que há dois utilizadores envolvidos aqui: o utilizador da MyApp e o utilizador do Google Drive. Neste caso, a MyApp precisa conhecer o utilizador da sua própria aplicação." }), "\n", _jsx(_components.p, { children: "Vamos ver um exemplo simples, assumindo que os utilizadores podem entrar na MyApp usando nome de utilizador e senha:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant IdP as Provedor de identidade (IdP)\n\n User->>MyApp: Abrir MyApp e
clicar \"Entrar\"\n MyApp->>IdP: Redirecionar para o IdP\n IdP->>User: Pedir nome de utilizador e senha\n User->>IdP: Inserir nome de utilizador e senha\n IdP->>IdP: Autenticar utilizador\n IdP->>MyApp: Redirecionar para a MyApp
com dados de autenticação e
autorização (por ex., token de ID)\n MyApp->>User: Exibir perfil do utilizador
(via ID token ou ponto de extremidade de userinfo)\n" }) }), "\n", _jsxs(_components.p, { children: ["Como estamos a autenticar o utilizador da nossa própria aplicação, normalmente não há necessidade de pedir permissão como o Google fez no fluxo OAuth 2.0. Entretanto, precisamos de algo que possa identificar o utilizador. O OpenID Connect introduz conceitos como ", _jsx(_components.strong, { children: "ID token" }), " e ", _jsx(_components.strong, { children: "ponto de extremidade de userinfo" }), " para nos ajudar com isso."] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsxs(_components.p, { children: ["Podes notar que o ", _jsx(_components.strong, { children: _jsx(_components.a, { href: "https://auth.wiki/identity-provider", children: "provedor de identidade (IdP)" }) }), " é um novo participante autónomo no fluxo. É o mesmo que o ", _jsx(_components.strong, { children: "servidor de autorização" }), " no OAuth 2.0, mas para maior clareza, usamos o termo IdP para mostrar que é responsável pela autenticação do utilizador e gestão de identidade."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Quando o teu negócio cresce, podes ter várias aplicações que compartilham a mesma base de dados de utilizadores. Assim como o OAuth 2.0, o OpenID Connect permite ter um único servidor de autorização que pode autenticar utilizadores para várias aplicações. Se o utilizador já entrou em uma aplicação, não precisa de inserir as suas credenciais novamente quando outra aplicação o redireciona para o IdP. O fluxo pode ser feito automaticamente sem interação do utilizador. Isso é chamado de single sign-on (SSO)." }), "\n", _jsx(_components.p, { children: "De novo, este é um fluxo altamente simplificado e há mais detalhes sob o capô. Por enquanto, vamos avançar para a próxima seção para evitar sobrecarga de informação." }), "\n", _jsxs(_components.h2, { id: "tipos-de-aplicação", children: ["Tipos de aplicação", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#tipos-de-aplicação", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Na seção anterior, usamos aplicações web como exemplos enquanto o mundo é mais diversificado do que isso. Para um provedor de identidade, a linguagem de programação exata, o framework ou a plataforma que usas realmente não importa. Na prática, uma diferença notável é se a aplicação é um ", _jsx(_components.a, { href: "https://auth.wiki/client#public-clients", children: "cliente público" }), " ou um ", _jsx(_components.a, { href: "https://auth.wiki/client#private-clients", children: "cliente privado (confiável)" }), ":"] }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Cliente público" }), ": Um cliente que não pode manter as suas credenciais confidenciais, o que significa que o proprietário do recurso (utilizador) pode acessá-las. Por exemplo, uma aplicação web a correr em um navegador (por exemplo, aplicação de página única)."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Cliente privado" }), ": Um cliente que tem a capacidade de manter as suas credenciais confidenciais sem as expor aos utilizadores (proprietários dos recursos). Por exemplo, uma aplicação web a correr num servidor (por exemplo, aplicação web do lado do servidor) ou um serviço de API."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Com isso em mente, vamos ver como o OAuth 2.0 e o OpenID Connect podem ser usados em diferentes tipos de aplicação." }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsx(_components.p, { children: "\"Aplicação\" e \"cliente\" podem ser usados de forma intercambiável no contexto deste post." }), "\n"] }), "\n", _jsxs(_components.h3, { id: "aplicações-web-a-correr-num-servidor", children: ["Aplicações web a correr num servidor", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplicações-web-a-correr-num-servidor", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "A aplicação corre num servidor e serve páginas HTML para os utilizadores. Muitos frameworks web populares como Express.js, Django, e Ruby on Rails caem nesta categoria; e frameworks backend-for-frontend (BFF) como Next.js e Nuxt.js também estão incluídos. Estas aplicações têm as seguintes características:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Como um servidor permite apenas acesso privado (não há maneira de utilizadores públicos verem o código ou credenciais do servidor), é considerado um cliente privado." }), "\n", _jsx(_components.li, { children: "O fluxo geral de autenticação de utilizador é o mesmo que discutimos na seção \"OpenID Connect\"." }), "\n", _jsx(_components.li, { children: "A aplicação pode usar o token de ID emitido pelo provedor de identidade (ou seja, o provedor de OpenID Connect) para identificar o utilizador e exibir conteúdo específico do utilizador." }), "\n", _jsxs(_components.li, { children: ["Para manter a aplicação segura, a aplicação geralmente usa o ", _jsx(_components.strong, { children: "fluxo de código de autorização" }), " para a autenticação do utilizador e para obter tokens."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Entretanto, a aplicação pode precisar de aceder a outros serviços de API internos numa arquitetura de microsserviços; ou é uma aplicação monolítica que precisa de controle de acesso para diferentes partes da aplicação. Discutiremos isto na seção \"Protege a tua API\"." }), "\n", _jsxs(_components.h3, { id: "aplicações-de-página-única-spas", children: ["Aplicações de página única (SPAs)", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplicações-de-página-única-spas", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "A aplicação corre no navegador de um utilizador e comunica-se com o servidor via APIs. React, Angular e Vue.js são frameworks populares para construir SPAs. Estas aplicações têm as seguintes características:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Como o código da aplicação é visível ao público, é considerado um cliente público." }), "\n", _jsx(_components.li, { children: "O fluxo geral de autenticação de utilizador é o mesmo que discutimos na seção \"OpenID Connect\"." }), "\n", _jsx(_components.li, { children: "A aplicação pode usar o token de ID emitido pelo provedor de identidade (ou seja, o provedor de OpenID Connect) para identificar o utilizador e exibir conteúdo específico do utilizador." }), "\n", _jsxs(_components.li, { children: ["Para manter a aplicação segura, a aplicação geralmente usa o ", _jsx(_components.strong, { children: "fluxo de código de autorização com PKCE (Prova de Chave para Troca de Código)" }), " para a autenticação do utilizador e para obter tokens."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Normalmente, as SPAs precisam de aceder a outros serviços de API para busca e atualização de dados. Discutiremos isso na seção \"Protege a tua API\"." }), "\n", _jsxs(_components.h3, { id: "aplicações-móveis", children: ["Aplicações móveis", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplicações-móveis", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "A aplicação corre num dispositivo móvel (iOS, Android, etc.) e comunica-se com o servidor via APIs. Na maioria dos casos, estas aplicações têm as mesmas características das SPAs." }), "\n", _jsxs(_components.h3, { id: "aplicações-de-máquina-para-máquina-m2m", children: ["Aplicações de máquina-para-máquina (M2M)", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplicações-de-máquina-para-máquina-m2m", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Aplicações ", _jsx(_components.a, { href: "https://auth.wiki/machine-to-machine", children: "máquina-para-máquina" }), " são ", _jsx(_components.a, { href: "https://auth.wiki/client", children: "clientes" }), " que correm num servidor (máquina) e comunicam-se com outros servidores. Estas aplicações têm as seguintes características:"] }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Assim como aplicações web a correr num servidor, aplicações M2M são clientes privados." }), "\n", _jsx(_components.li, { children: "A aplicação pode não precisar de identificar o utilizador; em vez disso, precisa de autenticar-se para aceder a outros serviços." }), "\n", _jsx(_components.li, { children: "A aplicação pode usar o token de acesso emitido pelo provedor de identidade (ou seja, o provedor de OAuth 2.0) para aceder a outros serviços." }), "\n", _jsxs(_components.li, { children: ["Para manter a aplicação segura, a aplicação geralmente usa o ", _jsx(_components.strong, { children: "fluxo de credenciais do cliente" }), " para obter tokens de acesso."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Ao aceder a outros serviços, a aplicação pode precisar de fornecer o token de acesso no cabeçalho da solicitação. Discutiremos isto na seção \"Protege a tua API\"." }), "\n", _jsxs(_components.h3, { id: "aplicações-a-correr-em-dispositivos-iot", children: ["Aplicações a correr em dispositivos IoT", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplicações-a-correr-em-dispositivos-iot", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "A aplicação corre num dispositivo IoT (por exemplo, dispositivos domésticos inteligentes, wearables, etc.) e comunica-se com o servidor via APIs. Estas aplicações têm as seguintes características:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Dependendo da capacidade do dispositivo, pode ser um cliente público ou privado." }), "\n", _jsx(_components.li, { children: "O fluxo geral de autenticação pode ser diferente do que discutimos na seção \"OpenID Connect\" de acordo com a capacidade do dispositivo. Por exemplo, alguns dispositivos podem não ter uma tela para os utilizadores inserirem suas credenciais." }), "\n", _jsx(_components.li, { children: "Se o dispositivo não precisar de identificar o utilizador, pode não precisar de usar tokens de ID ou pontos de extremidade de userinfo; em vez disso, pode ser tratado como uma aplicação de máquina-para-máquina (M2M)." }), "\n", _jsxs(_components.li, { children: ["Para manter a aplicação segura, a aplicação pode usar o ", _jsx(_components.strong, { children: "fluxo de código de autorização com PKCE (Prova de Chave para Troca de Código)" }), " para autenticação de utilizador e obter tokens ou o ", _jsx(_components.strong, { children: "fluxo de credenciais do cliente" }), " para obter tokens de acesso."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Ao comunicar com o servidor, o dispositivo pode precisar de fornecer o token de acesso no cabeçalho da solicitação. Discutiremos isto na seção \"Protege a tua API\"." }), "\n", _jsxs(_components.h2, { id: "protege-a-tua-api", children: ["Protege a tua API", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#protege-a-tua-api", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Com o OpenID Connect, é possível identificar o utilizador e buscar dados específicos do utilizador através de ", _jsx(_components.a, { href: "https://auth.wiki/id-token", children: "ID tokens" }), " ou ", _jsx(_components.a, { href: "https://auth.wiki/userinfo-endpoint", children: "pontos de extremidade de userinfo" }), ". Este processo é chamado de autenticação. Mas provavelmente não queres expor todos os teus recursos a todos os utilizadores autenticados, por exemplo, apenas administradores podem aceder à página de gestão de utilizadores."] }), "\n", _jsx(_components.p, { children: "Aqui é onde a autorização entra em jogo. Lembra que o OAuth 2.0 é uma estrutura de autorização, e o OpenID Connect é uma camada de identidade em cima do OAuth 2.0; o que significa que podes também usar o OAuth 2.0 quando o OpenID Connect já está em vigor." }), "\n", _jsxs(_components.p, { children: ["Vamos relembrar o exemplo que usamos na seção \"OAuth 2.0\": MyApp quer acessar o Google Drive do utilizador. Não é prático deixar a MyApp aceder a todos os arquivos do utilizador no Google Drive. Em vez disso, a MyApp deve reivindicar explicitamente o que quer aceder (por exemplo, acesso de leitura a arquivos em uma pasta específica). Nos termos do OAuth 2.0, isso é chamado de ", _jsx(_components.strong, { children: "escopo" }), "."] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsx(_components.p, { children: "Podes ver o termo \"permissão\" usado de forma intercambiável com \"escopo\" no contexto do OAuth 2.0, pois às vezes \"escopo\" é ambíguo para utilizadores não técnicos." }), "\n"] }), "\n", _jsx(_components.p, { children: "Quando o utilizador concede acesso à MyApp, o servidor de autorização emite um token de acesso com o escopo solicitado. O token de acesso é então enviado para o servidor de recursos (Google Drive) para acessar os arquivos do utilizador." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant Google\n\n User->>MyApp: Abrir MyApp e
clicar \"Conectar Google Drive\"\n MyApp->>Google: Redirecionar para o Google\n Google->>User: MyApp quer acessar o teu
Google Drive com escopo \"apenas leitura\"\n User->>Google: Ok, conceder acesso à MyApp\n Google->>MyApp: Redirecionar para a MyApp
com dados de autorização (por ex., token de acesso)\n MyApp->>Google: Acessar o Google Drive do utilizador
com token de acesso e escopo\n" }) }), "\n", _jsx(_components.p, { children: "Naturalmente, podemos substituir o Google Drive pelos nossos próprios serviços de API. Por exemplo, a MyApp precisa de acessar o OrderService para buscar o histórico de pedidos do utilizador. Desta vez, como a autenticação do utilizador já é feita pelo provedor de identidade e tanto a MyApp quanto o OrderService estão sob nosso controle, podemos pular a etapa de pedir ao utilizador para conceder acesso; a MyApp pode enviar diretamente a solicitação para o OrderService com o token de acesso emitido pelo provedor de identidade." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant OrderService\n\n User->>MyApp: Abrir histórico de pedidos\n MyApp->>OrderService: Buscar meu histórico de pedidos (com token de acesso)\n OrderService->>MyApp: Retornar histórico de pedidos\n MyApp->>User: Exibir histórico de pedidos\n" }) }), "\n", _jsxs(_components.p, { children: ["O token de acesso pode conter um ", _jsx(_components.code, { children: "read:order" }), " ", _jsx(_components.a, { href: "https://auth.wiki/scope", children: "escopo" }), " para indicar que o utilizador pode ler o seu histórico de pedidos."] }), "\n", _jsxs(_components.p, { children: ["Agora, digamos que o utilizador entra acidentalmente num URL de página de administrador no navegador. Como o utilizador não é um administrador, não há escopo ", _jsx(_components.code, { children: "admin" }), " no token de acesso. O OrderService rejeitará a solicitação e retornará uma mensagem de erro."] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant OrderService\n\n User->>MyApp: Abrir página de admin\n MyApp->>OrderService: Buscar página de admin (com token de acesso)\n OrderService->>MyApp: Erro: Acesso negado\n MyApp->>User: Exibir mensagem de erro\n" }) }), "\n", _jsx(_components.p, { children: "Neste caso, o OrderService pode retornar um código de status 403 Forbidden para indicar que o utilizador não está autorizado a aceder à página de administrador." }), "\n", _jsx(_components.p, { children: "Para aplicações de máquina-para-máquina (M2M), nenhum utilizador está envolvido no processo. As aplicações podem solicitar diretamente tokens de acesso do provedor de identidade e usá-los para aceder a outros serviços. O mesmo conceito aplica-se: o token de acesso contém os escopos necessários para aceder aos recursos." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant MyApp\n participant OrderService\n\n MyApp->>OrderService: Buscar todos os pedidos (com token de acesso)\n OrderService->>MyApp: Retornar todos os pedidos\n" }) }), "\n", _jsxs(_components.h3, { id: "design-de-autorização", children: ["Design de autorização", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#design-de-autorização", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Podemos ver duas coisas importantes a considerar ao projetar ", _jsx(_components.a, { href: "https://auth.wiki/authorization", children: "autorização" }), " para proteger os teus serviços de API:"] }), "\n", _jsxs(_components.ol, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Escopos" }), ": Define o que o cliente pode aceder. Os escopos podem ser detalhados (por exemplo, ", _jsx(_components.code, { children: "read:order" }), ", ", _jsx(_components.code, { children: "write:order" }), ") ou mais gerais (por exemplo, ", _jsx(_components.code, { children: "order" }), ") dependendo dos teus requisitos."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Controle de acesso" }), ": Define quem pode ter escopos específicos. Por exemplo, apenas administradores podem ter o escopo ", _jsx(_components.code, { children: "admin" }), "."] }), "\n"] }), "\n", _jsxs(_components.p, { children: ["Sobre ", _jsx(_components.a, { href: "https://auth.wiki/access-control", children: "controle de acesso" }), ", algumas abordagens populares são:"] }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Controle de acesso baseado em funções (RBAC)" }), ": Atribui funções aos utilizadores e define que funções podem aceder a que recursos. Por exemplo, uma função de administrador pode aceder à página de administrador."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Controle de acesso baseado em atributos (ABAC)" }), ": Define políticas com base em atributos (por exemplo, departamento do utilizador, localização, etc.) e toma decisões de controle de acesso com base nestes atributos. Por exemplo, um utilizador do departamento de \"Engenharia\" pode aceder à página de engenharia."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Vale a pena mencionar que para ambas as abordagens, a maneira padrão para verificar o controle de acesso é verificar os escopos dos tokens de acesso, em vez de funções ou atributos. Funções e atributos podem ser muito dinâmicos e os escopos são mais estáticos, o que facilita muito a gestão." }), "\n", _jsxs(_components.p, { children: ["Para informações detalhadas sobre controle de acesso, podes consultar ", _jsx(_components.a, { href: "https://blog.logto.io/rbac-and-abac", children: "RBAC e ABAC: Os modelos de controle de acesso que deves conhecer" }), "."] }), "\n", _jsxs(_components.h3, { id: "tokens-de-acesso", children: ["Tokens de acesso", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#tokens-de-acesso", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Embora tenhamos mencionado o termo \"", _jsx(_components.a, { href: "https://auth.wiki/access-token", children: "token de acesso" }), "\" várias vezes, não discutimos como obter um. No OAuth 2.0, um token de acesso é emitido pelo servidor de autorização (provedor de identidade) após um fluxo de autorização bem-sucedido."] }), "\n", _jsx(_components.p, { children: "Vamos dar uma olhada mais de perto no exemplo do Google Drive e assumir que estamos a usar o fluxo de código de autorização:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n autonumber\n participant User\n participant MyApp\n participant Google\n\n User->>MyApp: Abrir MyApp e
clicar \"Conectar Google Drive\"\n MyApp->>Google: Redirecionar para o Google\n Google->>User: Entrar no Google\n User->>Google: Entrar\n Google->>User: Pedir permissão
para acessar o Google Drive\n User->>Google: Conceder acesso a MyApp\n Google->>MyApp: Redirecionar para MyApp
com dados de autorização (por ex., código de autorização)\n MyApp->>Google: Usar código de autorização para
trocar por token de acesso\n Google->>MyApp: Retornar token de acesso\n MyApp->>Google: Acessar o Google Drive do utilizador com token de acesso\n" }) }), "\n", _jsx(_components.p, { children: "Há alguns passos importantes no fluxo para emissão de token de acesso:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: ["Passo 2 (Redirecionar para o Google): A MyApp redireciona o utilizador para o Google com uma ", _jsx(_components.strong, { children: "solicitação de autorização" }), ". Normalmente, esta solicitação inclui as seguintes informações:", "\n", _jsxs(_components.ul, { children: ["\n", _jsx(_components.li, { children: "Qual cliente (MyApp) está a iniciar a solicitação" }), "\n", _jsx(_components.li, { children: "Quais escopos a MyApp está a solicitar" }), "\n", _jsx(_components.li, { children: "Onde o Google deve redirecionar o utilizador após a autorização estar concluída" }), "\n"] }), "\n"] }), "\n", _jsxs(_components.li, { children: ["Passo 5 (Pedir permissão para acessar o Google Drive): O Google pede ao utilizador para conceder acesso à MyApp. O utilizador pode escolher conceder ou negar acesso. Este passo é chamado de ", _jsx(_components.strong, { children: "consentimento" }), "."] }), "\n", _jsxs(_components.li, { children: ["Passo 7 (Redirecionar para MyApp com dados de autorização): Este passo é recentemente introduzido no diagrama. Em vez de retornar o token de acesso diretamente, o Google retorna um ", _jsx(_components.strong, { children: "código de autorização" }), " de uso único para a MyApp para uma troca mais segura. Este código é usado para obter o token de acesso."] }), "\n", _jsxs(_components.li, { children: ["Passo 8 (Usar código de autorização para trocar por token de acesso): Este também é um novo passo. A MyApp envia o código de autorização para o Google para trocar por um token de acesso. Como provedor de identidade, o Google compõe o contexto da solicitação e decide se emite ou não um token de acesso:", "\n", _jsxs(_components.ul, { children: ["\n", _jsx(_components.li, { children: "O cliente (MyApp) é quem alega ser" }), "\n", _jsx(_components.li, { children: "O utilizador concedeu acesso ao cliente" }), "\n", _jsx(_components.li, { children: "O utilizador é quem alega ser" }), "\n", _jsx(_components.li, { children: "O utilizador possui os escopos necessários" }), "\n", _jsx(_components.li, { children: "O código de autorização é válido e não expirou" }), "\n"] }), "\n"] }), "\n"] }), "\n", _jsx(_components.p, { children: "O exemplo acima assume que o servidor de autorização (provedor de identidade) e o servidor de recursos são os mesmos (Google). Se forem separados, tomando o exemplo de MyApp e OrderService, o fluxo será assim:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n autonumber\n participant User\n participant MyApp\n participant IdP as Provedor de identidade (IdP)\n participant OrderService\n\n User->>MyApp: Abrir MyApp e
clicar \"Entrar\"\n MyApp->>IdP: Redirecionar para o IdP\n IdP->>User: Pedir nome de utilizador e senha\n User->>IdP: Inserir nome de utilizador e senha\n IdP->>IdP: Autenticar utilizador\n IdP->>MyApp: Redirecionar para a MyApp
com dados de autorização (por ex., código de autorização)\n MyApp->>IdP: Usar código de autorização para
trocar por tokens (ID token, token de acesso)\n IdP->>MyApp: Retornar tokens\n MyApp->>OrderService: Buscar meu histórico de pedidos (com token de acesso)\n OrderService->>OrderService: Verificar token de acesso\n OrderService->>MyApp: Retornar histórico de pedidos\n" }) }), "\n", _jsx(_components.p, { children: "Neste fluxo, o servidor de autorização (IdP) emite tanto um ID token quanto um token de acesso à MyApp (passo 8). O ID token é usado para identificar o utilizador, e o token de acesso é usado para aceder a outros serviços como OrderService. Como tanto a MyApp quanto o OrderService são serviços de primeira parte, geralmente não pedem ao utilizador para conceder acesso; em vez disso, confiam no controle de acesso no provedor de identidade para determinar se o utilizador pode aceder aos recursos (ou seja, se o token de acesso contém os escopos necessários)." }), "\n", _jsx(_components.p, { children: "Finalmente, vamos ver como o token de acesso é usado em aplicações de máquina-para-máquina (M2M). Como nenhum utilizador está envolvido no processo e a aplicação é confiável, ela pode solicitar diretamente um token de acesso do provedor de identidade:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n autonumber\n participant MyApp\n participant IdP as Provedor de identidade (IdP)\n participant OrderService\n\n MyApp->>IdP: Solicitar token de acesso\n IdP->>MyApp: Retornar token de acesso\n MyApp->>OrderService: Buscar todos os pedidos (com token de acesso)\n OrderService->>OrderService: Verificar token de acesso\n OrderService->>MyApp: Retornar todos os pedidos\n" }) }), "\n", _jsx(_components.p, { children: "O controle de acesso ainda pode ser aplicado aqui. Para o OrderService, não importa quem é o utilizador ou qual aplicação está a solicitar os dados; importa apenas o token de acesso e os escopos que ele contém." }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsxs(_components.p, { children: ["Tokens de acesso geralmente são codificados como JSON Web Tokens (JWT). Para aprender mais sobre JWT, podes consultar ", _jsx(_components.a, { href: "https://blog.logto.io/what-is-jwt", children: "O que é JSON Web Token (JWT)?" }), "."] }), "\n"] }), "\n", _jsxs(_components.h3, { id: "indicadores-de-recursos", children: ["Indicadores de recursos", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#indicadores-de-recursos", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "OAuth 2.0 introduz o conceito de escopos para controle de acesso. No entanto, podes rapidamente perceber que os escopos não são suficientes:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: ["OpenID Connect define um conjunto de escopos padrão como ", _jsx(_components.code, { children: "openid" }), ", ", _jsx(_components.code, { children: "offline_access" }), " e ", _jsx(_components.code, { children: "profile" }), ". Pode ser confuso misturar esses escopos padrão com os teus escopos personalizados."] }), "\n", _jsx(_components.li, { children: "Podes ter vários serviços de API que compartilham o mesmo nome de escopo, mas têm significados diferentes." }), "\n"] }), "\n", _jsxs(_components.p, { children: ["Uma solução comum é adicionar sufixos (ou prefixos) aos nomes dos escopos para indicar o recurso (serviço de API). Por exemplo, ", _jsx(_components.code, { children: "read:order" }), " e ", _jsx(_components.code, { children: "read:product" }), " são mais claros do que ", _jsx(_components.code, { children: "read" }), " e ", _jsx(_components.code, { children: "read" }), ". Uma extensão do OAuth 2.0 ", _jsx(_components.a, { href: "https://tools.ietf.org/html/rfc8707", children: "RFC 8707" }), " introduz um novo parâmetro ", _jsx(_components.code, { children: "resource" }), " para indicar o ", _jsx(_components.strong, { children: "servidor de recursos" }), " que o cliente quer aceder."] }), "\n", _jsxs(_components.p, { children: ["Na realidade, serviços de API geralmente são definidos por URLs, então é mais natural usar URLs como ", _jsx(_components.a, { href: "https://auth.wiki/resource-indicator", children: "indicadores de recursos" }), ". Por exemplo, a API do OrderService pode ser representada como:"] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { children: "https://api.example.com/orders\n" }) }), "\n", _jsxs(_components.p, { children: ["Como podes ver, o parâmetro traz a conveniência de usar os URLs reais de recursos nas solicitações de autorização e tokens de acesso. Vale a pena mencionar que o RFC 8707 pode não ser implementado por todos os provedores de identidade. Deves verificar a documentação do teu provedor de identidade para ver se ele suporta o parâmetro ", _jsx(_components.code, { children: "resource" }), " (Logto o suporta)."] }), "\n", _jsxs(_components.p, { children: ["Em resumo, o parâmetro ", _jsx(_components.code, { children: "resource" }), " pode ser usado em solicitações de autorização e tokens de acesso para indicar o recurso que o cliente deseja aceder."] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsxs(_components.p, { children: ["Não há restrições sobre a acessibilidade dos indicadores de recursos, isto é, o indicador de recurso não precisa ser um URL real que aponta para um serviço de API. Assim, o nome \"indicador de recurso\" reflete adequadamente o seu papel no processo de autorização. Podes usar URLs virtuais para representar recursos que desejas proteger. Por exemplo, podes definir um URL virtual ", _jsx(_components.code, { children: "https://api.example.com/admin" }), " na tua aplicação monolítica para representar o recurso que apenas administradores podem aceder."] }), "\n"] }), "\n", _jsxs(_components.h2, { id: "juntando-tudo", children: ["Juntando tudo", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#juntando-tudo", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Neste ponto, cobrimos o básico do OAuth 2.0 e OpenID Connect, e como usá-los em diferentes tipos de aplicação e cenários. Embora os tenhamos discutido separadamente, podes combiná-los de acordo com os teus requisitos de negócio. A arquitetura geral pode ser tão simples quanto isto:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "flowchart LR\n MyApp --- IdP\n" }) }), "\n", _jsx(_components.p, { children: "Ou um pouco mais complexa:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "flowchart LR\n WA[Aplicação web] --- IdP[Provedor de identidade]\n MA[Aplicação móvel] --- IdP\n OS[OrderService] --- IdP\n AS[AdminService] --- IdP\n WA --- OS\n MA --- OS\n SA[Aplicação de página única] --- IdP\n SA --- AS\n OS --- AS\n" }) }), "\n", _jsx(_components.p, { children: "À medida que a tua aplicação cresce, verás que o provedor de identidade (IdP) desempenha um papel crítico na arquitetura; mas isso não se relaciona diretamente aos objetivos do teu negócio. Embora seja uma ótima ideia transferi-lo para um fornecedor confiável, precisamos escolher o provedor de identidade sabiamente. Um bom provedor de identidade pode simplificar muito o processo, reduzir o esforço de desenvolvimento e salvar-te de possíveis armadilhas de segurança." }), "\n", _jsxs(_components.h2, { id: "notas-finais", children: ["Notas finais", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#notas-finais", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Para aplicações modernas em nuvem, o provedor de identidade (ou servidor de autorização) é o ponto central para ", _jsx(_components.a, { href: "https://auth.wiki/authentication", children: "autenticação" }), " de utilizadores, ", _jsx(_components.a, { href: "https://auth.wiki/iam", children: "gestão de identidade" }), " e ", _jsx(_components.a, { href: "https://auth.wiki/access-control", children: "controle de acesso" }), ". Embora tenhamos discutido muitos conceitos neste post, ainda há muitas nuances a considerar ao implementar tal sistema. Se estiveres interessado em aprender mais, podes navegar pelo nosso blog para artigos mais aprofundados."] }), "\n", _jsx(LogtoCloudButton, {})] }); } function MDXContent(props = {}) { const {wrapper: MDXLayout} = { ..._provideComponents(), ...props.components }; return MDXLayout ? _jsx(MDXLayout, { ...props, children: _jsx(_createMdxContent, { ...props }) }) : _createMdxContent(props); } return { headings, readingTime, frontmatter, default: MDXContent }; function _missingMdxReference(id, component) { throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it."); }