Partilhar via

Proteja aplicativos e APIs validando declarações

  • Artigo

A interação com tokens é uma parte central da criação de aplicativos para autorizar usuários. De acordo com o princípio Zero Trust para acesso menos privilegiado, é essencial que os aplicativos validem os valores de certas declarações presentes no token de acesso ao executar a autorização.

A autorização baseada em declarações permite que os aplicativos garantam que o token contenha os valores corretos para coisas como o locatário, o assunto e o ator presentes no token. Dito isto, a autorização baseada em declarações pode parecer complexa, dados os vários métodos a utilizar e os cenários a controlar. Este artigo pretende simplificar o processo de autorização baseado em declarações para que você possa garantir que seus aplicativos sigam as práticas mais seguras.

Para garantir que sua lógica de autorização seja segura, você deve validar as seguintes informações nas declarações:

  • O público apropriado é especificado para o token.
  • A ID do locatário do token corresponde à ID do locatário onde os dados são armazenados.
  • O assunto do token é apropriado.
  • O ator (aplicativo cliente) é autorizado.

Nota

Os tokens de acesso só são validados nas APIs da Web para as quais foram adquiridos por um cliente. O cliente não deve validar tokens de acesso.

Para obter mais informações sobre as declarações mencionadas neste artigo, consulte Tokens de acesso à plataforma de identidade da Microsoft.

Validar o público

A aud declaração identifica o público-alvo do token. Antes de validar declarações, você sempre deve verificar se o valor da declaração contida no token de aud acesso corresponde à API da Web. O valor pode depender de como o cliente solicitou o token. O público no token de acesso depende do ponto de extremidade:

  • Para tokens v2.0, a audiência é o ID do cliente da API da Web. É um GUID.
  • Para tokens v1.0, a audiência é um dos URIs appID declarados na API da Web que valida o token. Por exemplo, api://{ApplicationID}ou um nome exclusivo começando com um nome de domínio (se o nome de domínio estiver associado a um locatário).

Para obter mais informações sobre o URI appID de um aplicativo, consulte URI de ID do aplicativo.

Validar o inquilino

Sempre verifique se o tid em um token corresponde ao ID do locatário usado para armazenar dados com o aplicativo. Quando as informações são armazenadas para um aplicativo no contexto de um locatário, elas só devem ser acessadas novamente posteriormente no mesmo locatário. Nunca permita que os dados de um inquilino sejam acedidos a partir de outro inquilino.

A validação do locatário é apenas a primeira etapa, e as verificações sobre assunto e ator descritas neste artigo ainda são necessárias. Se sua intenção for autorizar todos os usuários em um locatário, é altamente recomendável adicionar explicitamente esses usuários a um grupo e autorizar com base no grupo. Por exemplo, verificando apenas o ID do locatário e a presença de uma oid declaração, sua API pode autorizar inadvertidamente todas as entidades de serviço nesse locatário, além dos usuários.

Validar o assunto

Determine se o assunto do token, como o usuário (ou o próprio aplicativo para um token somente de aplicativo), está autorizado.

Você pode verificar se há reivindicações específicas sub ou oid reivindicações.

Ou,

Você pode verificar se o assunto pertence a uma função ou grupo apropriado com as rolesdeclarações , scp, groups, wids . Por exemplo, use os valores tid de declaração imutáveis e oid como uma chave combinada para dados de aplicativo e determinar se um usuário deve receber acesso.

As rolesdeclarações , groups ou wids também podem ser usadas para determinar se o sujeito tem autorização para executar uma operação, embora não sejam uma lista exaustiva de todas as maneiras pelas quais um sujeito pode receber permissões. Por exemplo, um administrador pode ter permissão para gravar em uma API, mas não um usuário normal, ou o usuário pode estar em um grupo com permissão para executar alguma ação. A wid declaração representa as funções de todo o locatário atribuídas ao usuário a partir das funções presentes nas funções internas do Microsoft Entra. Para obter mais informações, veja Funções incorporadas do Microsoft Entra.

Aviso

Nunca use declarações como email, preferred_username ou unique_name para armazenar ou determinar se o usuário em um token de acesso deve ter acesso aos dados. Essas declarações não são exclusivas e podem ser controladas por administradores de locatários ou, às vezes, usuários, o que as torna inadequadas para decisões de autorização. Eles só são utilizáveis para fins de exibição. Também não use a upn reivindicação para autorização. Embora o UPN seja único, ele geralmente muda ao longo da vida útil de um usuário principal, o que o torna não confiável para autorização.

Validar o ator

Um aplicativo cliente que está agindo em nome de um usuário (referido como o ator), também deve ser autorizado. Use a scp declaração (escopo) para validar se o aplicativo tem permissão para executar uma operação. As permissões em scp devem ser limitadas ao que o usuário realmente precisa e segue os princípios de menor privilégio.

No entanto, há ocorrências em que scp não está presente no token. Você deve verificar a ausência da scp reivindicação para os seguintes cenários:

  • Daemon apps / app only permission
  • Tokens de ID

Para obter mais informações sobre escopos e permissões, consulte Escopos e permissões na plataforma de identidade da Microsoft.

Nota

Um aplicativo pode manipular tokens somente de aplicativo (solicitações de aplicativos sem usuários, como aplicativos daemon) e deseja autorizar um aplicativo específico em vários locatários, em vez de IDs de entidade de serviço individuais. Nesse caso, a appid declaração (para tokens v1.0) ou a azp declaração (para tokens v2.0) pode ser usada para autorização de assunto. No entanto, ao usar essas declarações, o aplicativo deve garantir que o token foi emitido diretamente para o aplicativo, validando a idtyp declaração opcional. Somente tokens do tipo app podem ser autorizados dessa forma, pois tokens de usuário delegado podem ser potencialmente obtidos por entidades diferentes do aplicativo.

Próximos passos