Customizando os tokens
Com o App ID, os tokens são usados para identificar usuários e proteger seus recursos. É possível optar por customizar as informações que são injetadas nos tokens pelo serviço. Ao injetar as informações em seus tokens, elas ficam disponíveis para o aplicativo em tempo de execução, sem a necessidade de configurar chamadas de rede adicionais. Para obter mais informações sobre tokens e como eles são usados no App ID, consulte Entendendo os tokens.
Ao customizar a sua configuração do token, é possível assegurar que suas necessidades de segurança e de experiência do usuário sejam atendidas. No entanto, caso um token se torne comprometido, um usuário malicioso poderá ter mais informações ou tempo que poderão ser usados para afetar o seu aplicativo. Tenha certeza de que você entende as implicações de segurança das customizações que deseja fazer antes de fazê-las.
Entendendo o mapeamento de solicitações customizadas
Uma solicitação é uma instrução que uma entidade faz sobre si mesmo ou em nome de outra pessoa. Por exemplo, se você se conectar a um aplicativo usando um provedor de identidade, o provedor enviará ao aplicativo um grupo de reclamações ou instruções sobre você para o app para que ele possa agrupar com informações que ele já sabe sobre você. Dessa forma, ao se conectar, o aplicativo é configurado com suas informações, da maneira que você o configurou.
Quais tipos de solicitações posso definir?
As solicitações que são fornecidas pelo App ID se enquadram em várias categorias que são diferenciadas por seu nível de customização.
- Solicitações normalizadas
- Em cada token de identidade, há um conjunto de solicitações que é reconhecido pelo App ID como normalizado. Quando disponível, as solicitações são mapeadas diretamente do seu provedor de identidade para o token por padrão. As solicitações
não podem ser explicitamente omitidas, mas podem ser sobrescritas em seu token por solicitações customizadas. As solicitações incluem
name
,email
,picture
elocale
. - Solicitações restritas
- As solicitações restritas são aquelas que têm possibilidades de customização limitadas e não podem ser sobrescritas por mapeamentos customizados. Para um token de acesso, o
scope
é a única solicitação restrita. Embora não possa ser sobrescrita, ela pode ser estendida com o seu próprio escopo. Quando um escopo é mapeado para um token de acesso, o valor deve ser uma sequência e não pode ser prefixado porappid_
ou ele será ignorado. Em tokens de identidade, as solicitaçõesidentities
eoauth_clients
não podem ser modificadas ou sobrescritas. - Solicitações registradas
- As solicitações registradas estão presentes em seus tokens de acesso e de identidade e são definidas pelo App ID. Elas não podem ser substituídas por mapeamentos customizados. Essas solicitações são ignoradas pelo serviço
e incluem
iss
,aud
,sub
,iat
,exp
,amr
etenant
.
A definição de uma solicitação para o seu token não muda ou elimina o atributo. Ela muda as informações que estão presentes no token no tempo de execução.
Como as reivindicações são mapeadas para os tokens?
Cada mapeamento é definido por um objeto de origem de dados e uma chave que é usada para recuperar a solicitação. Será possível injetar até 100 solicitações em cada token se a carga útil máxima permanecer menor que 100 KB. Se desejar usar
as solicitações aninhadas, será possível incluí-las usando a sintaxe de ponto. Por exemplo, nested.attribute
.
As solicitações são configuradas para cada token separadamente e são aplicadas sequencialmente conforme mostrado no exemplo a seguir.
{
"accessTokenClaims": [
{
"source": "saml",
"sourceClaim": "moderator"
},
{
"source": "saml",
"sourceClaim": "viewer",
"destinationClaim": "reader"
}
],
"idTokenClaims": [
{
"source": "saml",
"sourceClaim": "attributes.uid"
},
{
"source": "saml",
"sourceClaim": "Name",
"destinationClaim": "firstName"
},
{
"source": "saml",
"sourceClaim": "Country"
}
]
}
Object | Descrição |
---|---|
source |
Define a origem da solicitação. As opções incluem: saml , cloud_directory , facebook , google , appid_custom e attributes . |
sourceClaim |
Define a solicitação conforme fornecida pela origem. Pode se referir às informações sobre o usuário do provedor de identidade ou aos atributos customizados do App ID do usuário. |
destinationClaim |
Opcional: define o atributo customizado que pode substituir a solicitação atual em token. |
Configurando os tokens
Com a API, é possível customizar as informações que são retornadas em seus tokens do App ID.
Se desejar configurar o tempo de vida de seu token, será possível fazer as mudanças rapidamente por meio do painel de serviço. Para obter mais informações, consulte Gerenciando a autenticação.
-
No terminal, execute o comando a seguir para obter uma chave de API.
ibmcloud iam api-key-create NAME [-d DESCRIPTION] [-f, --file FILE]
Compreensão das opções do comando de criação de uma chave de API Opção Descrição NAME
O nome que você quer dar à sua chave. Por exemplo, myKey
.DESCRIPTION
Uma descrição da chave ou de seu uso. Por exemplo, "This is my App ID API key"
.FILE
O local no qual você deseja armazenar a sua chave. Por exemplo, key_file
. -
Obtenha um token do IAM usando a chave de API que você obteve na etapa prévia.
curl -k -X POST "https://iam.cloud.ibm.com/identity/token" \ --header "Content-Type: application/x-www-form-urlencoded" \ --header "Accept: application/json" \ --data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" \ --data-urlencode "apikey=<apiKey>"
-
Obtém o ID do locatário para sua instância do serviço. É possível localizar o valor em seu serviço ou nas credenciais de aplicativo.
-
Faça uma solicitação de PUT para o terminal
/config/tokens
com a sua configuração de token.curl -X PUT "https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/config/tokens" \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer <IAMToken>" \ -d '{ "access": { "expires_in": 3600 }, "refresh": { "enabled": true, "expires_in": 2592001 }, "anonymousAccess": { "enabled": false }, "accessTokenClaims": [ { "source": "roles" }, { "source": "saml", "sourceClaim": "name_id", "destinationClaim": "id" } ], "idTokenClaims": [ { "source": "saml", "sourceClaim": "attributes.uid" } ] }'
Compreensão da configuração do token Variável Descrição access: expires_in
A duração da validade dos tokens de acesso. Quanto menor o valor, maior a proteção que você tem em casos de roubo de token. O valor é fornecido em segundos e pode ser qualquer número inteiro no intervalo de 300
a86400
. O valor padrão é3600
.refresh: expires_in
A duração da validade dos tokens de atualização. Quanto menor o valor, maior a proteção que você tem em casos de roubo de token. O valor é fornecido em segundos e pode ser qualquer número inteiro no intervalo de 86400
a7776000
. O valor padrão é2592000
(30 dias).anonymousAccess
A duração da validade de um token anônimo. Os tokens anônimos são designados para os usuários no momento em que começam a interagir com o seu app. Quando um usuário se conectar, as informações no token anônimo serão, então, transferidas para o token associado ao usuário. O valor é fornecido em segundos e pode ser qualquer número inteiro no intervalo de 86400
a7776000
. O valor padrão é2592000
(30 dias).accessTokenClaims
Uma matriz que contém os objetos criados quando as solicitações que estão relacionadas a tokens de acesso são mapeadas. Você pode querer incluir informações sobre funções ou atributos específicos que são retornados por um provedor de identidade de escolha de um usuário. Nota: se você já estiver usando uma solicitação customizada com o título "funções" do seu provedor de identidade, assegure-se de usar uma solicitação de destino para ver ambos os valores. idTokenClaims
Uma matriz que contém as informações que estão presentes em tokens quando você mapeia solicitações em tokens de identidade. Dependendo da sua configuração, você também pode escolher ter "funções" presentes em seu token de identidade. Deve-se configurar o tempo de vida do token em cada solicitação que você fizer. Se um valor não for configurado, o padrão será usado. Cada solicitação de customização sobrescreve o que foi configurado anteriormente. Observe que as especificações de configuração de tempo de vida da API são diferentes das do painel de serviço.
-
Após o token ser retornado e você decodificá-lo, você verá um resultado semelhante ao exemplo a seguir:
{ "sub" : "1234567890", "name" : "John Doe", "exp" : 1564566, "roles" : ["admin", "manager"], "id": "<nameIDFromSaml>", "attributes.uid": "<uidFromSaml>" ... }