Esta página aplica-se ao Apigee e ao Apigee Hybrid.
Veja a documentação do
Apigee Edge.
A política VerifyJWT valida um JWT assinado ou desencripta e valida um JWT encriptado recebido de clientes ou outros sistemas. Esta política também extrai as reivindicações para variáveis de contexto, para que as políticas ou as condições subsequentes possam examinar esses valores para tomar decisões de autorização ou encaminhamento. Consulte a vista geral das políticas de JWS e JWT para ver uma introdução detalhada.
Quando esta política é executada, no caso de um JWT assinado, o Apigee valida a assinatura do JWT através da chave de validação fornecida. No caso de um JWT encriptado, o Apigee desencripta o JWT através da chave de desencriptação. Em qualquer dos casos, o Apigee verifica posteriormente se o JWT é válido de acordo com as horas de validade e de início, se estiverem presentes. Opcionalmente, a política também pode validar os valores de reivindicações específicas no JWT, como o assunto, o emissor, o público-alvo ou o valor de reivindicações adicionais.
Se o JWT for validado e for válido, todas as reivindicações contidas no JWT são extraídas para variáveis de contexto para utilização por políticas ou condições subsequentes, e o pedido pode prosseguir. Se não for possível validar a assinatura JWT ou se o JWT for inválido devido a um dos registos de data/hora, todo o processamento é interrompido e é devolvido um erro na resposta.
Se a política valida um JWT assinado ou encriptado, depende do elemento que usa para especificar o algoritmo que valida o JWT:
- Se usar o elemento
<Algorithm>, a política valida um JWT assinado. - Se usar o elemento
<Algorithms>, a política valida um JWT encriptado.
Esta política é uma política padrão e pode ser implementada em qualquer tipo de ambiente. Para obter informações sobre os tipos de políticas e a disponibilidade com cada tipo de ambiente, consulte Tipos de políticas.
Para saber mais sobre as partes de um JWT e como são encriptadas e assinadas, consulte o RFC7519.
Valide um JWT assinado
Esta secção explica como validar um JWT assinado. Para um JWT assinado,
use o elemento <Algorithm>
para especificar o algoritmo de assinatura da chave.
Exemplos de um JWT assinado
Os exemplos seguintes ilustram como validar um JWT assinado.
Algoritmo HS256
Esta política de exemplo valida um JWT que foi assinado com o algoritmo de encriptação HS256, HMAC
usando uma soma de verificação SHA-256. O JWT é transmitido no pedido de proxy através de um parâmetro de formulário denominado
jwt. A chave está contida numa variável denominada private.secretkey.
Consulte o vídeo acima para ver um exemplo completo, incluindo como fazer um pedido à política.
A configuração da política inclui as informações de que o Apigee precisa para descodificar e avaliar o JWT, como onde encontrar o JWT (numa variável de fluxo especificada no elemento Source), o algoritmo de assinatura necessário, onde encontrar a chave secreta (armazenada numa variável de fluxo do Apigee, que pode ter sido obtida no KVM do Apigee, por exemplo) e um conjunto de reivindicações necessárias e os respetivos valores.
<VerifyJWT name="JWT-Verify-HS256">
<DisplayName>JWT Verify HS256</DisplayName>
<Algorithm>HS256</Algorithm>
<Source>request.formparam.jwt</Source>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<SecretKey encoding="base64">
<Value ref="private.secretkey"/>
</SecretKey>
<Subject>monty-pythons-flying-circus</Subject>
<Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
<Audience>fans</Audience>
<AdditionalClaims>
<Claim name="show">And now for something completely different.</Claim>
</AdditionalClaims>
</VerifyJWT>A política escreve o respetivo resultado em variáveis de contexto para que as políticas ou as condições subsequentes no proxy de API possam examinar esses valores. Consulte o artigo Variáveis de fluxo para ver uma lista das variáveis definidas por esta política.
Algoritmo RS256
Esta política de exemplo valida um JWT que foi assinado com o algoritmo RS256. Para validar,
tem de fornecer a chave pública. O JWT é transmitido no pedido de proxy através de um parâmetro de formulário
denominado jwt. A chave pública está contida numa variável denominada public.publickey.
Consulte o vídeo acima para ver um exemplo completo, incluindo como fazer um pedido à política.
Consulte a Referência de elementos para ver detalhes sobre os requisitos e as opções de cada elemento nesta política de exemplo.
<VerifyJWT name="JWT-Verify-RS256">
<Algorithm>RS256</Algorithm>
<Source>request.formparam.jwt</Source>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<PublicKey>
<Value ref="public.publickey"/>
</PublicKey>
<Subject>apigee-seattle-hatrack-montage</Subject>
<Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
<Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
<AdditionalClaims>
<Claim name="show">And now for something completely different.</Claim>
</AdditionalClaims>
</VerifyJWT>Para a configuração acima, um JWT com este cabeçalho …
{
"typ" : "JWT",
"alg" : "RS256"
}E esta carga útil…
{
"sub" : "apigee-seattle-hatrack-montage",
"iss" : "urn://apigee-edge-JWT-policy-test",
"aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
"show": "And now for something completely different."
}… vai ser considerada válida se a assinatura puder ser validada com a chave pública fornecida.
Um JWT com o mesmo cabeçalho, mas com este payload…
{
"sub" : "monty-pythons-flying-circus",
"iss" : "urn://apigee-edge-JWT-policy-test",
"aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
"show": "And now for something completely different."
}… vai ser considerada inválida, mesmo que seja possível validar a assinatura, porque a reivindicação "sub" incluída no JWT não corresponde ao valor necessário do elemento "Subject" conforme especificado na configuração da política.
A política escreve o respetivo resultado em variáveis de contexto para que as políticas ou as condições subsequentes no proxy de API possam examinar esses valores. Consulte o artigo Variáveis de fluxo para ver uma lista das variáveis definidas por esta política.
Os exemplos acima usam o elemento <Algorithm>, pelo que validam um JWT assinado. O elemento <PrivateKey> especifica a chave usada para assinar o JWT. Também existem outros elementos importantes. A que usa depende do algoritmo especificado pelo valor de <Algorithm>, conforme descrito na secção seguinte.
Definir os elementos principais para validar um JWT assinado
Os seguintes elementos especificam a chave usada para validar um JWT assinado:
O elemento que usa depende do algoritmo escolhido, conforme apresentado na tabela seguinte:
| Algoritmo | Elementos principais | |
|---|---|---|
| HS* |
<SecretKey encoding="base16|hex|base64|base64url"> <Value ref="private.secretkey"/> </SecretKey> |
|
| RS*, ES*, PS* | <PublicKey> <Value ref="rsa_public_key_or_value"/> </PublicKey> ou: <PublicKey> <Certificate ref="signed_cert_val_ref"/> </PublicKey> ou: <PublicKey> <JWKS ref="jwks_val_or_ref"/> </PublicKey> |
|
| *Para mais informações sobre os requisitos de chaves, consulte o artigo Acerca dos algoritmos de encriptação de assinaturas. | ||
Valide um JWT encriptado
Esta secção explica como validar um JWT encriptado. Para um JWT encriptado, use o elemento
<Algorithms>
para especificar os algoritmos de assinatura da chave e do conteúdo.
Exemplo de um JWT encriptado
O exemplo seguinte mostra como validar um JWT encriptado (com <Type>
definido como Encrypted), em que:
- A chave está encriptada com o algoritmo RSA-OAEP-256.
- O conteúdo está encriptado com o algoritmo A128GCM.
<VerifyJWT name="vjwt-1"> <Algorithms> <Key>RSA-OAEP-256</Key> <Content>A128GCM</Content> </Algorithms> <Type>Encrypted</Type> <PrivateKey> <Value ref="private.rsa_privatekey"/> </PrivateKey> <Subject>subject@example.com</Subject> <Issuer>urn://apigee</Issuer> <AdditionalHeaders> <Claim name="moniker">Harvey</Claim> </AdditionalHeaders> <TimeAllowance>30s</TimeAllowance> <Source>input_var</Source> </VerifyJWT>
O exemplo acima usa o elemento <Algorithms>, pelo que valida um JWT encriptado. O elemento <PrivateKey> especifica a chave que vai ser usada para desencriptar o JWT. Também existem outros elementos importantes. A que usa depende do algoritmo especificado pelo valor de <Algorithms>, conforme descrito na secção seguinte.
Definir os elementos principais para validar um JWT encriptado
Os seguintes elementos especificam a chave usada para validar um JWT encriptado:
O elemento que usa depende do algoritmo de encriptação de chaves escolhido, conforme mostrado na tabela seguinte:
| Algoritmo | Elementos principais |
|---|---|
| RSA-OAEP-256 | <PrivateKey> <Value ref="private.rsa_privatekey"/> </PrivateKey> Nota: a variável que especificar tem de ser resolvida para uma chave privada RSA no formato codificado em PEM. |
|
<PrivateKey> <Value ref="private.ec_privatekey"/> </PrivateKey> Nota: a variável que especificar tem de ser resolvida para uma chave privada de curva elíptica no formato com codificação PEM. |
|
<SecretKey encoding="base16|hex|base64|base64url"> <Value ref="private.flow-variable-name-here"/> </SecretKey> |
|
<PasswordKey> <Value ref="private.password-key"/> <SaltLength> <PBKDF2Iterations> </PasswordKey> |
| dir | <DirectKey> <Value encoding="base16|hex|base64|base64url" ref="private.directkey"/> </DirectKey> |
Para mais informações sobre os principais requisitos, consulte o artigo Acerca dos algoritmos de encriptação de assinatura.
Referência do elemento
A referência da política descreve os elementos e os atributos da política Verify JWT.
Nota: a configuração varia ligeiramente consoante o algoritmo de encriptação que usar. Consulte as amostras para ver exemplos que demonstram configurações para exemplos de utilização específicos.
Atributos que se aplicam ao elemento de nível superior
<VerifyJWT name="JWT" continueOnError="false" enabled="true" async="false">
Os seguintes atributos são comuns a todos os elementos principais da política.
| Atributo | Descrição | Predefinição | Presença |
|---|---|---|---|
| nome |
O nome interno da política. Os carateres que pode usar no nome estão restritos a:
A-Z0-9._\-$ %. No entanto, a IU do Apigee aplica restrições adicionais, como a remoção automática de carateres que não sejam alfanuméricos.
Opcionalmente, use o elemento |
N/A | Obrigatória |
| continueOnError |
Defina como false para devolver um erro quando uma política falha. Este comportamento é o esperado para a maioria das políticas.
Definido como |
falso | Opcional |
| ativada |
Defina como true para aplicar a política.
Defina como |
verdadeiro | Opcional |
| assíncrono | Este atributo foi descontinuado. | falso | Descontinuado |
<DisplayName>
<DisplayName>Policy Display Name</DisplayName>
Use em conjunto com o atributo name para etiquetar a política no editor de proxy da IU de gestão com um nome diferente em linguagem natural.
| Predefinição | Se omitir este elemento, é usado o valor do atributo name da política. |
| Presença | Opcional |
| Tipo | String |
<Algorithm>
<Algorithm>HS256</Algorithm>
Especifica o algoritmo criptográfico usado para validar o token. Use o elemento <Algorithm> para validar um JWT assinado.
Os algoritmos RS*/PS*/ES* usam um par de chaves pública/secreta, enquanto os algoritmos HS* usam um segredo partilhado. Consulte também Acerca dos algoritmos de encriptação de assinaturas.
Pode especificar vários valores separados por vírgulas. Por exemplo, "HS256, HS512" ou "RS256, PS256". No entanto, não pode combinar algoritmos HS* com outros nem algoritmos ES* com outros, porque requerem um tipo de chave específico. Pode combinar algoritmos RS* e PS*.
| Predefinição | N/A |
| Presença | Obrigatória |
| Tipo | String de valores separados por vírgulas |
| Valores válidos | HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384 e PS512 |
<Algorithms>
<Algorithms>
<Key>key-algorithm</Key>
<Content>content-algorithm</Content>
</Algorithm>Use o elemento <Algorithms> para validar um JWT encriptado. Este elemento
especifica o algoritmo criptográfico para a encriptação de chaves que tem de ter sido usado quando
o JWT encriptado foi criado. Também especifica opcionalmente o algoritmo
para a encriptação de conteúdo.
| Predefinição | N/A |
| Presença | Obrigatório quando valida um JWT encriptado |
| Tipo | Complexo |
Elementos secundários de <Algorithms>
A tabela seguinte apresenta uma descrição geral dos elementos subordinados de
<Algorithms>:
| Elemento secundário | Obrigatório? | Descrição |
|---|---|---|
<Key> |
Obrigatória | Especifica o algoritmo de encriptação da chave. |
<Content> |
Opcional | Especifica o algoritmo de encriptação do conteúdo. |
A validação falha se:
- O algoritmo declarado na propriedade
algno cabeçalho do JWT encriptado é diferente do algoritmo de encriptação de chaves especificado aqui no elemento<Key>. -
A política especifica um elemento
<Content>e o algoritmo afirmado na propriedadeencno cabeçalho do JWT encriptado é diferente do especificado no elemento<Content>.
Por exemplo, para validar um JWT encriptado e verificar se o algoritmo da chave é RSA-OAEP-256 e se o algoritmo de conteúdo é A128GCM:
<Algorithms>
<Key>RSA-OAEP-256</Key>
<Content>A128GCM</Content>
</Algorithms>Por outro lado, para validar um JWT encriptado e verificar se o algoritmo de chave é
RSA-OAEP-256 e não aplicar uma restrição ao algoritmo de conteúdo:
<Algorithms>
<Key>RSA-OAEP-256</Key>
</Algorithms>Algoritmos de encriptação de chaves
A tabela seguinte apresenta os algoritmos disponíveis para a encriptação de chaves, bem como o tipo de chave que tem de especificar para validar um JWT através desse algoritmo de encriptação de chaves.
Valor de <Key> (algoritmo de encriptação de chaves) |
Elemento essencial necessário para a validação |
|---|---|
| dir | <DirectKey> |
| RSA-OAEP-256 | <PrivateKey> |
|
<SecretKey> |
|
<PasswordKey> |
|
<PrivateKey> |
Consulte o artigo Validar um JWT encriptado para ver um exemplo em que o algoritmo de encriptação de chaves é RSA-OAEP-256, pelo que usa o elemento <PrivateKey>.
Algoritmos de encriptação de conteúdo
A política VerifyJWT não requer que especifique um algoritmo para a encriptação de conteúdo. Se quiser especificar o algoritmo usado para a encriptação de conteúdo, faça-o com o elemento filho<Content> do elemento <Algorithms>.
Independentemente do algoritmo de encriptação de chaves, os seguintes algoritmos, todos simétricos e baseados em AES, são suportados para a encriptação de conteúdo:
- A128CBC-HS256
- A192CBC-HS384
- A256CBC-HS512
- A128GCM
- A192GCM
- A256GCM
<Audience>
<Audience>audience-here</Audience> or: <Audience ref='variable-name-here'/>
A política verifica se a reivindicação de público no JWT corresponde ao valor especificado na configuração. Se não houver correspondência, a política gera um erro. Esta reivindicação identifica os destinatários a quem o JWT se destina. Esta é uma das reivindicações registadas mencionadas na RFC7519.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String |
| Valores válidos | Uma variável ou uma string de fluxo que identifica o público-alvo. |
<AdditionalClaims/Claim>
<AdditionalClaims> <Claim name='claim1'>explicit-value-of-claim-here</Claim> <Claim name='claim2' ref='variable-name-here'/> <Claim name='claim3' ref='variable-name-here' type='boolean'/> </AdditionalClaims> or: <AdditionalClaims ref='claim_payload'/>
Valida se a carga útil do JWT contém as reivindicações adicionais especificadas e se os valores das reivindicações afirmadas correspondem.
Uma reivindicação adicional usa um nome que não é um dos nomes de reivindicações JWT padrão e registados. O valor de uma reivindicação adicional pode ser uma string, um número, um valor booleano, um mapa ou uma matriz. Um mapa é simplesmente um conjunto de pares de nome/valor. O valor de uma reivindicação de qualquer um destes tipos pode ser especificado explicitamente na configuração da política ou indiretamente através de uma referência a uma variável de fluxo.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String, número, booleano ou mapa |
| Array | Defina como true para indicar se o valor é uma matriz de tipos. Predefinição: false |
| Valores válidos | Qualquer valor que queira usar para uma reivindicação adicional. |
O elemento <Claim> aceita os seguintes atributos:
- name: (obrigatório) o nome da reivindicação.
- ref: (opcional) o nome de uma variável de fluxo. Se estiver presente, a política usa o valor desta variável como a reivindicação. Se forem especificados um atributo ref e um valor de reivindicação explícito, o valor explícito é o predefinido e é usado se a variável de fluxo referenciada não for resolvida.
- type: (opcional) um dos seguintes: string (predefinição), number, boolean ou map
- array: (opcional) defina como verdadeiro para indicar se o valor é uma matriz de tipos. Predefinição: false.
Quando inclui o elemento <Claim>, os nomes das reivindicações são definidos estaticamente quando
configura a política. Em alternativa, pode transmitir um objeto JSON para especificar os nomes das reivindicações.
Uma vez que o objeto JSON é transmitido como uma variável, os nomes das reivindicações são determinados no momento da execução.
Por exemplo:
<AdditionalClaims ref='json_claims'/>
Em que a variável json_claims contém um objeto JSON no formato:
{ "sub" : "person@example.com", "iss" : "urn://secure-issuer@example.com", "non-registered-claim" : { "This-is-a-thing" : 817, "https://example.com/foobar" : { "p": 42, "q": false } } }
<AdditionalHeaders/Claim>
<AdditionalHeaders> <Claim name='claim1'>explicit-value-of-claim-here</Claim> <Claim name='claim2' ref='variable-name-here'/> <Claim name='claim3' ref='variable-name-here' type='boolean'/> <Claim name='claim4' ref='variable-name' type='string' array='true'/> </AdditionalHeaders>
Valida se o cabeçalho JWT contém os pares de nome/valor de reivindicação adicionais especificados e se os valores de reivindicação afirmados correspondem.
Uma reivindicação adicional usa um nome que não é um dos nomes de reivindicações JWT padrão e registados. O valor de uma reivindicação adicional pode ser uma string, um número, um valor booleano, um mapa ou uma matriz. Um mapa é simplesmente um conjunto de pares de nome/valor. O valor de uma reivindicação de qualquer um destes tipos pode ser especificado explicitamente na configuração da política ou indiretamente através de uma referência a uma variável de fluxo.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo |
String (predefinição), número, booleano ou mapa. O tipo é predefinido como String se não for especificado nenhum tipo. |
| Array | Defina como true para indicar se o valor é uma matriz de tipos. Predefinição: false |
| Valores válidos | Qualquer valor que queira usar para uma reivindicação adicional. |
O elemento <Claim> aceita os seguintes atributos:
- name: (obrigatório) o nome da reivindicação.
- ref: (opcional) o nome de uma variável de fluxo. Se estiver presente, a política usa o valor desta variável como a reivindicação. Se forem especificados um atributo ref e um valor de reivindicação explícito, o valor explícito é o predefinido e é usado se a variável de fluxo referenciada não for resolvida.
- type: (opcional) um dos seguintes: string (predefinição), number, boolean ou map
- array: (opcional) defina como verdadeiro para indicar se o valor é uma matriz de tipos. Predefinição: false.
<CustomClaims>
Nota: atualmente, é inserido um elemento CustomClaims quando adiciona uma nova política GenerateJWT através da IU. Este elemento não é funcional e é ignorado. O elemento correto a usar é <AdditionalClaims>. A IU vai ser atualizada para inserir os elementos corretos mais tarde.
<Id>
<Id>explicit-jti-value-here</Id> -or- <Id ref='variable-name-here'/> -or- <Id/>
Verifica se o JWT tem a reivindicação jti específica. Quando o valor de texto e o atributo ref estão ambos vazios, a política gera um jti que contém um UUID aleatório. A reivindicação de ID do JWT (jti) é um identificador exclusivo do JWT. Para mais informações sobre jti, consulte o RFC7519.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String ou referência. |
| Valores válidos | Uma string ou o nome de uma variável de fluxo que contém o ID. |
<IgnoreCriticalHeaders>
<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>
Defina como falso se quiser que a política apresente um erro quando qualquer cabeçalho listado no cabeçalho crit do JWT não estiver listado no elemento <KnownHeaders>.
Defina como verdadeiro para fazer com que a política VerifyJWT ignore o cabeçalho crit.
Um dos motivos para definir este elemento como verdadeiro é se estiver num ambiente de teste e ainda não estiver preparado para processar uma falha num cabeçalho em falta.
| Predefinição | falso |
| Presença | Opcional |
| Tipo | Booleano |
| Valores válidos | verdadeiro ou falso |
<IgnoreIssuedAt>
<IgnoreIssuedAt>true|false</IgnoreIssuedAt>
Defina como falso (predefinição) se quiser que a política apresente um erro quando um JWT contém uma reivindicação iat (Emitido em) que especifica uma hora no futuro.
Defina como verdadeiro para fazer com que a política ignore o iat durante a validação.
| Predefinição | falso |
| Presença | Opcional |
| Tipo | Booleano |
| Valores válidos | verdadeiro ou falso |
<IgnoreUnresolvedVariables>
<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>
Defina como falso se quiser que a política apresente um erro quando qualquer variável referenciada especificada na política não for resolvível. Defina como true para tratar qualquer variável não resolúvel como uma string vazia (nula).
| Predefinição | falso |
| Presença | Opcional |
| Tipo | Booleano |
| Valores válidos | verdadeiro ou falso |
<Issuer>
<VerifyJWT name='VJWT-29'> ... <!-- verify that the iss claim matches a hard-coded value --> <Issuer>issuer-string-here</Issuer> or: <!-- verify that the iss claim matches the value contained in a variable --> <Issuer ref='variable-containing-issuer'/> or: <!-- verify via a variable; fallback to a hard-coded value if the variable is empty --> <Issuer ref='variable-containing-issuer'>fallback-value-here</Issuer>
A política verifica se o emissor no JWT (a reivindicação iss) corresponde à string
especificada no elemento de configuração. A reivindicação iss é uma das reivindicações registadas
mencionadas na RFC 7519 da IETF.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String ou referência |
| Valores válidos | Qualquer |
<KnownHeaders>
<KnownHeaders>a,b,c</KnownHeaders> or: <KnownHeaders ref='variable_containing_headers'/>
A política GenerateJWT usa o elemento <CriticalHeaders> para preencher o cabeçalho
crit num JWT. Por exemplo:
{
"typ": "...",
"alg" : "...",
"crit" : [ "a", "b", "c" ],
}A política VerifyJWT examina o cabeçalho crit no JWT, se existir, e, para cada cabeçalho listado, verifica se o elemento <KnownHeaders> também lista esse cabeçalho. O elemento
<KnownHeaders> pode conter um superconjunto dos itens listados em crit.
Só é necessário que todos os cabeçalhos indicados em crit estejam indicados no elemento
<KnownHeaders>. Qualquer cabeçalho que a política encontre em crit
que também não esteja listado em <KnownHeaders> faz com que a política VerifyJWT falhe.
Opcionalmente, pode configurar a política VerifyJWT para ignorar o cabeçalho crit definindo o elemento <IgnoreCriticalHeaders> como true.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | Matriz de strings separadas por vírgulas |
| Valores válidos | Uma matriz ou o nome de uma variável que contém a matriz. |
<MaxLifespan>
<VerifyJWT name='VJWT-62'> ... <!-- hard-coded lifespan of 5 minutes --> <MaxLifespan>5m</MaxLifespan> or: <!-- refer to a variable --> <MaxLifespan ref='variable-here'/> or: <!-- attribute telling the policy to use iat rather than nbf --> <MaxLifespan useIssueTime='true'>1h</MaxLifespan> or: <!-- useIssueTime and ref, and hard-coded fallback value. --> <MaxLifespan useIssueTime='true' ref='variable-here'>1h</MaxLifespan> ...
Configura a política VerifyJWT para verificar se a duração de um token não excede um limite especificado. Pode especificar o limite usando um número seguido de um caráter, que indica o número de segundos, minutos, horas, dias ou semanas. Os seguintes carateres são válidos:
s- segundosm- minutosh- horasddiasw- semanas
Por exemplo, pode especificar um dos seguintes valores: 120s, 10m, 1h, 7d, 3w.
A política calcula a duração real do token subtraindo o valor not-before (nbf) do valor de validade (exp). Se
exp ou nbf estiver em falta, a política gera uma falha. Se a duração do token exceder o período especificado, a política gera uma falha.
Pode definir o atributo opcional useIssueTime como true para usar o valor iat em vez do valor nbf ao calcular a duração do token.
A utilização do elemento MaxLifespan
é opcional. Se usar este elemento, só o pode usar uma vez.
<PrivateKey>
Use este elemento para especificar a chave privada que pode ser usada para validar um JWT encriptado com um algoritmo assimétrico. Segue-se uma descrição dos possíveis elementos secundários.
<Password>
<PrivateKey> <Password ref="private.privatekey-password"/> </PrivateKey>
Um elemento secundário do elemento <PrivateKey>. Especifica a palavra-passe que a política deve usar para desencriptar a chave privada, se necessário, ao validar um JWT encriptado.
Use o atributo ref para transmitir a palavra-passe numa variável de fluxo.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String |
| Valores válidos |
Uma referência de variável de fluxo.
Nota: tem de especificar uma variável de fluxo. O Apigee rejeita como inválida uma configuração de política em que a palavra-passe é especificada em texto simples. A variável de fluxo
tem de ter o prefixo "private". Por exemplo, |
<Value>
<PrivateKey> <Value ref="private.variable-name-here"/> </PrivateKey>
Elemento subordinado do elemento <PrivateKey>. Especifica uma chave privada codificada em PEM
que a política vai usar para validar um JWT encriptado. Use o atributo ref para transmitir a chave
numa variável de fluxo.
| Predefinição | N/A |
| Presença | Necessário para validar um JWT que foi encriptado com um algoritmo de encriptação de chaves assimétricas. |
| Tipo | String |
| Valores válidos |
Uma variável de fluxo que contém uma string que representa um valor de chave privada RSA codificado em PEM.
Nota: a variável de fluxo tem de ter o prefixo "private". Por exemplo,
|
<PublicKey>
Especifica a origem da chave pública usada para validar um JWT assinado com um algoritmo assimétrico. Os algoritmos de suporte incluem: RS256/RS384/RS512, PS256/PS384/PS512 ou ES256/ES384/ES512. Segue-se uma descrição dos possíveis elementos subordinados.
<Certificate>
<PublicKey> <Certificate ref="signed_public.cert"/> </PublicKey> -or- <PublicKey> <Certificate> -----BEGIN CERTIFICATE----- certificate data -----END CERTIFICATE----- </Certificate> </PublicKey>
Um elemento secundário do elemento <PublicKey>. Especifica o certificado assinado
usado como a origem da chave pública. Use o atributo ref
para transmitir o certificado assinado numa variável de fluxo ou especifique o certificado codificado em PEM
diretamente. Certifique-se de que alinha os dados do certificado à esquerda, conforme mostrado
no exemplo de referência.
| Predefinição | N/A |
| Presença | Opcional. Para validar um JWT assinado com um algoritmo assimétrico, tem de usar o elemento <Certificate>, o elemento <JWKS> ou o elemento <Value> para fornecer a chave pública. |
| Tipo | String |
| Valores válidos | Uma variável de fluxo ou uma string. |
<JWKS>
<PublicKey>
<JWKS … > … </JWKS>
</PublicKey>Um elemento secundário do elemento <PublicKey>. Especifica um JWKS como uma origem de chaves públicas. Esta será uma lista de chaves seguindo o formato descrito no documento
IETF RFC 7517 – Chave Web JSON (JWK).
Se o JWT de entrada tiver um ID da chave presente no JWKS, a política usa a chave pública correta para validar a assinatura do JWT. Para ver detalhes acerca desta funcionalidade, consulte o artigo Usar um conjunto de chaves Web JSON (JWKS) para validar um JWT.
Se obtiver o valor de um URL público, o Apigee armazena em cache o JWKS durante um período de 300 segundos. Quando a cache expira, o Apigee obtém novamente o JWKS.
| Predefinição | N/A |
| Presença | Opcional. Para validar um JWT assinado com um algoritmo assimétrico, tem de usar o elemento <Certificate>, o elemento <JWKS> ou o elemento <Value> para fornecer a chave pública. |
| Tipo | String |
| Valores válidos |
Pode especificar o JWKS de uma das quatro formas seguintes:
|
<Value>
<PublicKey> <Value ref="public.publickeyorcert"/> </PublicKey> -or- <PublicKey> <Value> -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2kPrRzcufvUNHvTH/WW ...YOUR PUBLIC KEY MATERIAL HERE....d1lH8MfUyRXmpmnNxJHAC2F73IyN ZmkDb/DRW5onclGzxQITBFP3S6JXd4LNESJcTp705ec1cQ9Wp2Kl+nKrKyv1E5Xx DQIDAQAB -----END PUBLIC KEY----- </Value> </PublicKey>
Um elemento secundário do elemento <PublicKey>. Especifica a chave pública a usar para validar a assinatura num JWT assinado. Use o atributo ref para transmitir a chave
numa variável de fluxo ou especifique a chave codificada em PEM diretamente. Certifique-se de que alinha a chave pública à esquerda, conforme mostrado no exemplo de referência.
| Predefinição | N/A |
| Presença | Opcional. Para validar um JWT assinado com um algoritmo assimétrico, tem de usar o elemento <Certificate>, o elemento <JWKS> ou o elemento <Value> para fornecer a chave pública. |
| Tipo | String |
| Valores válidos | Uma variável de fluxo ou uma string. |
<RequiredClaims>
<VerifyJWT name='VJWT-1'> ... <!-- Directly specify the names of the claims to require --> <RequiredClaims>sub,iss,exp</RequiredClaims> -or- <!-- Specify the claim names indirectly, via a context variable --> <RequiredClaims ref='claims_to_require'/> ... </VerifyJWT>
O elemento <RequiredClaims> é opcional. Especifica uma lista de nomes separados por vírgulas
de reivindicações que têm de estar presentes na carga útil do JWT quando se valida um JWT. O elemento
garante que o JWT apresentado contém as reivindicações necessárias, mas não valida o conteúdo
das reivindicações. Se alguma das reivindicações indicadas não estiver presente, a política VerifyJWT gera uma falha em tempo de execução.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String |
| Valores válidos | Uma lista de nomes de reivindicações separados por vírgulas. |
<SecretKey>
<SecretKey encoding="base16|hex|base64|base64url" > <Value ref="private.your-variable-name"/> </SecretKey>
O elemento SecretKey é opcional. Especifica a chave secreta a usar quando validar um JWT assinado que usa um algoritmo simétrico (HS*) ou quando validar um JWT encriptado que usa um algoritmo simétrico (AES) para a encriptação de chaves.
Filhos de <SecretKey>
A tabela seguinte fornece uma descrição dos elementos e atributos secundários de
<SecretKey>:
| Filho | Presença | Descrição |
|---|---|---|
| codificação (atributo) | Opcional | Especifica como a chave é codificada na variável referenciada. Por predefinição, quando não está presente o atributo <SecretKey encoding="hex" > <Value ref="private.secretkey"/> </SecretKey> No exemplo acima, uma vez que a codificação é |
| Valor (elemento) | Obrigatória | Uma chave secreta codificada. Especifica a chave secreta que vai ser usada
para validar a carga útil. Use o atributo <SecretKey> <Value ref="private.my-secret-variable"/> </SecretKey> O Apigee aplica uma intensidade mínima da chave para os algoritmos HS256/HS384/HS512. O comprimento mínimo da chave para HS256 é de 32 bytes, para HS384 é de 48 bytes e para HS512 é de 64 bytes. A utilização de uma chave de menor força provoca um erro de tempo de execução. |
<Source>
<Source>jwt-variable</Source>
Se presente, especifica a variável de fluxo na qual a política espera encontrar o JWT para validar.
Com este elemento, pode configurar a política para obter o JWT de um formulário ou de uma variável de parâmetro de consulta ou qualquer outra variável. Quando este elemento está presente, a política não remove nenhum prefixo Bearer que possa estar presente. Se a variável não existir ou se a política não encontrar um JWT na variável especificada, a política devolve um erro.
Por predefinição, quando não está presente nenhum elemento <Source>, a política obtém o JWT lendo a variável request.header.authorization e removendo o prefixo Bearer. Se transmitir o JWT no cabeçalho de autorização como um token de portador
(com o prefixo Bearer), não especifique o elemento <Source>
na configuração da política. Por exemplo, não usaria nenhum elemento <Source> na configuração da política se passasse o JWT no cabeçalho de autorização da seguinte forma:
curl -v https://api-endpoint/proxy1_basepath/api1 -H "Authorization: Bearer eyJhbGciOiJ..."
| Predefinição | request.header.authorization (Consulte a nota acima para ver informações importantes
acerca da predefinição). |
| Presença | Opcional |
| Tipo | String |
| Valores válidos | Um nome de variável de fluxo do Apigee. |
<Subject>
<VerifyJWT name='VJWT-8'> ... <!-- verify that the sub claim matches a hard-coded value --> <Subject>subject-string-here</Subject> or: <!-- verify that the sub claim matches the value contained in a variable --> <Subject ref='variable-containing-subject'/> or: <!-- verify via a variable; fallback to a hard-coded value if the variable is empty --> <Subject ref='variable-containing-subject'>fallback-value-here</Subject>
A política verifica se o assunto no JWT (a reivindicação sub) corresponde à string
especificada na configuração da política. A reivindicação sub é uma das reivindicações registadas descritas na RFC7519.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String |
| Valores válidos | Qualquer valor que identifique exclusivamente um assunto. |
<TimeAllowance>
<VerifyJWT name='VJWT-23'> ... <!-- configure a hard-coded time allowance of 20 seconds --> <TimeAllowance>20s</TimeAllowance> or: <!-- refer to a variable containing the time allowance --> <TimeAllowance ref='variable-containing-time-allowance'/> or: <!-- refer to a variable; fallback to a hard-coded value if the variable is empty --> <TimeAllowance ref='variable-containing-allowance'>30s</TimeAllowance>
O "período de tolerância" para horas, para ter em conta a diferença de tempo entre o emissor e o validador de um JWT. Isto aplica-se tanto à data de validade (a reivindicação exp) como ao
not-before-time (a reivindicação nbf). Por exemplo, se o tempo permitido estiver configurado
para 30s, um JWT expirado é tratado como ainda válido durante 30 segundos
após a validade declarada. O not-before-time é avaliado de forma semelhante.
| Predefinição | 0 segundos (sem período de tolerância) |
| Presença | Opcional |
| Tipo | String |
| Valores válidos |
Uma expressão de intervalo de tempo ou uma referência a uma variável de fluxo que contém uma expressão.
Os intervalos de tempo podem ser especificados por um número inteiro positivo seguido de um caráter que indica
uma unidade de tempo, da seguinte forma:
|
<Type>
<Type>type-string-here</Type>
Descreve se a política valida um JWT assinado ou um JWT encriptado.
O elemento <Type> é opcional. Pode usá-lo para informar os leitores da configuração se a política gera um JWT assinado ou encriptado.
- Se o elemento
<Type>estiver presente:- Se o valor de
<Type>forSigned, a política valida um JWT assinado e o elemento<Algorithm>tem de estar presente. - Se o valor de
<Type>forEncrypted, a política valida um JWT encriptado e o elemento<Algorithms>tem de estar presente.
- Se o valor de
- Se o elemento
<Type>estiver ausente:- Se o elemento
<Algorithm>estiver presente, a política assume que<Type>éSigned. - Se o elemento
<Algorithms>estiver presente, a política assume que<Type>éEncrypted.
- Se o elemento
- Se não estiver presente nem
<Algorithm>nem<Algorithms>, a configuração é inválida.
| Predefinição | N/A |
| Presença | Opcional |
| Tipo | String |
| Valores válidos | Signed ou Encrypted |
Flow variables
Upon success, the Verify JWT and Decode JWT policies set context variables according to this pattern:
jwt.{policy_name}.{variable_name}
For example, if the policy name is jwt-parse-token , then the policy will store
the subject specified in the JWT to the context variable named jwt.jwt-parse-token.decoded.claim.sub.
(For backward compatibility, it will also be available in jwt.jwt-parse-token.claim.subject)
| Variable name | Description |
|---|---|
claim.audience |
The JWT audience claim. This value may be a string, or an array of strings. |
claim.expiry |
The expiration date/time, expressed in milliseconds since epoch. |
claim.issuedat |
The Date the token was issued, expressed in milliseconds since epoch. |
claim.issuer |
The JWT issuer claim. |
claim.notbefore |
If the JWT includes a nbf claim, this variable will contain the value, expressed in milliseconds since epoch. |
claim.subject |
The JWT subject claim. |
claim.name |
The value of the named claim (standard or additional) in the payload. One of these will be set for every claim in the payload. |
decoded.claim.name |
The JSON-parsable value of the named claim (standard or additional) in the payload. One variable is set for
every claim in the payload. For example, you can use decoded.claim.iat to
retrieve the issued-at time of the JWT, expressed in seconds since epoch. While you
can also use the claim.name flow variables, this is the
recommended variable to use to access a claim. |
decoded.header.name |
The JSON-parsable value of a header in the payload. One variable is set for
every header in the payload. While you can also use the header.name flow variables,
this is the recommended variable to use to access a header. |
expiry_formatted |
The expiration date/time, formatted as a human-readable string. Example: 2017-09-28T21:30:45.000+0000 |
header.algorithm |
The signing algorithm used on the JWT. For example, RS256, HS384, and so on. See (Algorithm) Header Parameter for more. |
header.kid |
The Key ID, if added when the JWT was generated. See also "Using a JSON Web Key Set (JWKS)" at JWT policies overview to verify a JWT. See (Key ID) Header Parameter for more. |
header.type |
Will be set to JWT. |
header.name |
The value of the named header (standard or additional). One of these will be set for every additional header in the header portion of the JWT. |
header-json |
The header in JSON format. |
is_expired |
true or false |
payload-claim-names |
An array of claims supported by the JWT. |
payload-json |
The payload in JSON format.
|
seconds_remaining |
The number of seconds before the token will expire. If the token is expired, this number will be negative. |
time_remaining_formatted |
The time remaining before the token will expire, formatted as a human-readable string. Example: 00:59:59.926 |
valid |
In the case of VerifyJWT, this variable will be true when the signature is verified, and
the current time is before the token expiry, and after the token notBefore value, if they
are present. Otherwise false.
In the case of DecodeJWT, this variable is not set. |
Referência de erro
This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.
Runtime errors
These errors can occur when the policy executes.
| Fault code | HTTP status | Occurs when |
|---|---|---|
steps.jwt.AlgorithmInTokenNotPresentInConfiguration |
401 |
Occurs when the verification policy has multiple algorithms. |
steps.jwt.AlgorithmMismatch |
401 |
The algorithm specified in the Generate policy did not match the one expected in the
Verify policy. The algorithms specified must match. |
steps.jwt.FailedToDecode |
401 |
The policy was unable to decode the JWT. The JWT is possibly corrupted. |
steps.jwt.GenerationFailed |
401 |
The policy was unable to generate the JWT. |
steps.jwt.InsufficientKeyLength |
401 |
For a key less than 32 bytes for the HS256 algorithm, less than 48 bytes for the HS386 algortithm, and less than 64 bytes for the HS512 algorithm. |
steps.jwt.InvalidClaim |
401 |
For a missing claim or claim mismatch, or a missing header or header mismatch. |
steps.jwt.InvalidConfiguration |
401 |
Both the <Algorithm> and <Algorithms> elements
are present. |
steps.jwt.InvalidCurve |
401 |
The curve specified by the key is not valid for the Elliptic Curve algorithm. |
steps.jwt.InvalidIterationCount |
401 |
The iteration count that was used in the encrypted JWT is not equal to the iteration
count specified in the VerifyJWT policy configuration. This applies only to JWT that
use <PasswordKey>. |
steps.jwt.InvalidJsonFormat |
401 |
Invalid JSON found in the header or payload. |
steps.jwt.InvalidKeyConfiguration |
401 |
JWKS in the <PublicKey> element is invalid. The reason
could be that the JWKS URI endpoint is not reachable from the Apigee instance. Test
connectivity to the endpoint by creating a passthrough proxy and using the JWKS endpoint
as a target. |
steps.jwt.InvalidSaltLength |
401 |
The salt length that was used in the encrypted JWT is not equal to the salt length
specified in the VerifyJWT policy configuration. This applies only to JWT that
use <PasswordKey>. |
steps.jwt.InvalidPasswordKey |
401 |
The specified key specified did not meet the requirements. |
steps.jwt.InvalidPrivateKey |
401 |
The specified key specified did not meet the requirements. |
steps.jwt.InvalidPublicKey |
401 |
The specified key specified did not meet the requirements. |
steps.jwt.InvalidSecretKey |
401 |
The specified key specified did not meet the requirements. |
steps.jwt.InvalidToken |
401 |
This error occurs when the JWT signature verification fails. |
steps.jwt.JwtAudienceMismatch |
401 |
The audience claim failed on token verification. |
steps.jwt.JwtIssuerMismatch |
401 |
The issuer claim failed on token verification. |
steps.jwt.JwtSubjectMismatch |
401 |
The subject claim failed on token verification. |
steps.jwt.KeyIdMissing |
401 |
The Verify policy uses a JWKS as a source for public keys, but the signed JWT does not
include a kid property in the header. |
steps.jwt.KeyParsingFailed |
401 |
The public key could not be parsed from the given key information. |
steps.jwt.NoAlgorithmFoundInHeader |
401 |
Occurs when the JWT contains no algorithm header. |
steps.jwt.NoMatchingPublicKey |
401 |
The Verify policy uses a JWKS as a source for public keys, but the kid
in the signed JWT is not listed in the JWKS. |
steps.jwt.SigningFailed |
401 |
In GenerateJWT, for a key less than the minimum size for the HS384 or HS512 algorithms |
steps.jwt.TokenExpired |
401 |
The policy attempts to verify an expired token. |
steps.jwt.TokenNotYetValid |
401 |
The token is not yet valid. |
steps.jwt.UnhandledCriticalHeader |
401 |
A header found by the Verify JWT policy in the crit header is not
listed in KnownHeaders. |
steps.jwt.UnknownException |
401 |
An unknown exception occurred. |
steps.jwt.WrongKeyType |
401 |
Wrong type of key specified. For example, if you specify an RSA key for an Elliptic Curve algorithm, or a curve key for an RSA algorithm. |
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
| Error name | Cause | Fix |
|---|---|---|
InvalidNameForAdditionalClaim |
The deployment will fail if the claim used in the child element <Claim>
of the <AdditionalClaims> element is one of the following registered names:
kid, iss, sub, aud, iat,
exp, nbf, or jti.
|
build |
InvalidTypeForAdditionalClaim |
If the claim used in the child element <Claim>
of the <AdditionalClaims> element is not of type string, number,
boolean, or map, the deployment will fail.
|
build |
MissingNameForAdditionalClaim |
If the name of the claim is not specified in the child element <Claim>
of the <AdditionalClaims> element, the deployment will fail.
|
build |
InvalidNameForAdditionalHeader |
This error ccurs when the name of the claim used in the child element <Claim>
of the <AdditionalClaims> element is either alg or typ.
|
build |
InvalidTypeForAdditionalHeader |
If the type of claim used in the child element <Claim>
of the <AdditionalClaims> element is not of type string, number,
boolean, or map, the deployment will fail.
|
build |
InvalidValueOfArrayAttribute |
This error occurs when the value of the array attribute in the child element <Claim>
of the <AdditionalClaims> element is not set to true or false.
|
build |
InvalidValueForElement |
If the value specified in the <Algorithm> element is not a supported value,
the deployment will fail.
|
build |
MissingConfigurationElement |
This error will occur if the <PrivateKey> element is not used with
RSA family algorithms or the <SecretKey> element is not used with HS Family
algorithms.
|
build |
InvalidKeyConfiguration |
If the child element <Value> is not defined in the <PrivateKey>
or <SecretKey> elements, the deployment will fail.
|
build |
EmptyElementForKeyConfiguration |
If the ref attribute of the child element <Value> of the <PrivateKey>
or <SecretKey> elements is empty or unspecified, the deployment will fail.
|
build |
InvalidConfigurationForVerify |
This error occurs if the <Id> element is defined within the
<SecretKey> element.
|
build |
InvalidEmptyElement |
This error occurs if the <Source> element of the Verify JWT policy
is empty. If present, it must be defined with an Apigee flow variable name.
|
build |
InvalidPublicKeyValue |
If the value used in the child element <JWKS> of the <PublicKey> element
does not use a valid format as specified in RFC 7517,
the deployment will fail.
|
build |
InvalidConfigurationForActionAndAlgorithm |
If the <PrivateKey> element is used with HS Family algorithms or
the <SecretKey> element is used with RSA Family algorithms, the
deployment will fail.
|
build |
Fault variables
These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.
| Variables | Where | Example |
|---|---|---|
fault.name="fault_name" |
fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. | fault.name Matches "InvalidToken" |
JWT.failed |
All JWT policies set the same variable in the case of a failure. | JWT.failed = true |
Example error response
For error handling, the best practice is to trap the errorcode part of the error
response. Do not rely on the text in the faultstring, because it could change.
Example fault rule
<FaultRules>
<FaultRule name="JWT Policy Errors">
<Step>
<Name>JavaScript-1</Name>
<Condition>(fault.name Matches "InvalidToken")</Condition>
</Step>
<Condition>JWT.failed=true</Condition>
</FaultRule>
</FaultRules>