Registro dinâmico de clientes com o novo provedor OpenID Connect
O Registro de Cliente Dinâmico permite que a Parte Dependente (RP) do OpenID Connect (OIDC) se registre com o OpenID Connect Provider (OP).
Antes de começar
Baseia-se nas especificações do OpenID Connect Dynamic Client Registration 1.0.
Novos aplicativos OIDC são criados por um administrador de locatários ou por um usuário com acesso administrativo ao locatário. Agora, as aplicações OIDC também podem ser criadas dinamicamente por meio do registro dinâmico de clientes.
O terminal de registro do cliente dinâmico está localizado aqui: https://{{tenant}}/oauth2/register.
Sobre esta tarefa
Configure as definições de registro dinâmico de clientes e, em seguida, registre dinamicamente o novo aplicativo OIDC usando a API de registro. O aplicativo é um aplicativo do tipo " ""OpenID Connect" ou " ""OpenID Connect for Open Banking".
Configurações dinâmicas de registro de clientes
As configurações de registro dinâmico de clientes podem ser definidas para estabelecer os valores padrão para o registro dinâmico de clientes. Consulte “Configurando as definições de registro dinâmico de clientes OIDC ”.
As configurações relevantes estão descritas na tabela a seguir.
| Campo | Descrição |
|---|---|
| Tipos de concessão | Os tipos de concessão a serem utilizados caso não estejam especificados na carga útil do registro dinâmico do cliente. Os tipos de autorização suportados são "Código de autorização", "Implícita", "Senha", "Token de atualização" e "Credenciais do cliente". Se a receita do Open Banking não for “Nenhuma”, o tipo de concessão “Senha” não é permitido. |
| Solicitações de token de ID | As solicitações padrão para o token de identificação e as informações do usuário, caso não sejam especificadas na carga útil do registro dinâmico do cliente. |
| Solicitações de token | As solicitações padrão para introspecção e token de acesso JWT, caso não sejam especificadas na carga útil do registro dinâmico do cliente. |
| Tipo de token de acesso | O tipo de token de acesso a ser gerado. Os valores válidos são "Padrão" e "JWT". |
| Algoritmo de assinatura do token de ID | O algoritmo utilizado para assinar tokens de identificação, caso não seja especificado na carga útil do registro dinâmico do cliente. |
| Consentimento do usuário | Selecione se deseja solicitar o consentimento do usuário caso isso não esteja especificado na carga de dados do registro dinâmico do cliente. |
| Tempo de vida do token de acesso | A validade do token de acesso em segundos. Máximo 2147483647, mínimo 1. |
| Tempo de vida do token de atualização | O tempo de validade do token de atualização em segundos. Máximo 2147483647, mínimo 1. |
| Aplicar a verificação PKCE | Selecione se deseja aplicar o PKCE caso isso não esteja especificado na carga útil do registro dinâmico do cliente. |
| Autorizar a todos os usuários | Verifique se todos os usuários têm permissão para usar este cliente, caso isso não esteja especificado na carga de registro dinâmico do cliente. |
| Período de validade do objeto de solicitação | O período de validade do objeto de solicitação, em segundos. Máximo 2147483647, mínimo 1. |
| Requerer "exp" para o objeto da solicitação | Determina se o atributo “exp” é obrigatório no objeto de solicitação. |
| Permitir credenciais customizadas do cliente | Determina se credenciais personalizadas do cliente são permitidas. Se definido como "false", o ID do cliente e o segredo não poderão ser especificados na carga de dados do registro dinâmico do cliente. |
| Algoritmos de assinatura de objetos da solicitação permitidos | Uma lista dos algoritmos de assinatura permitidos para o JWT da solicitação assinada. Se não for definido, todos os algoritmos compatíveis serão permitidos. |
| Regra de transformação da solicitação | Insira a regra para modificar a solicitação de registro de cliente dinâmico. Se não for definido, nenhuma alteração será feita na solicitação de registro dinâmico do cliente. |
| Receita do Open Banking | A receita de Open Banking a ser aplicada a todos os registros dinâmicos de clientes. Quando este campo é definido como "Nenhum", é criada uma aplicação " 'OpenID Connect". Se for definido com qualquer outro valor, será criada uma aplicação « 'OpenID Connect for Open Banking». |
Consulte a seção "Configuração das definições de registro dinâmico de clientes OIDC " para as seções "Declaração de software", "Solicitar autorização" e "Token de acesso de registro" das configurações.
Requerer autenticação de token de acesso para registro de cliente dinâmico
Se a autorização da solicitação estiver configurada para exigir a autorização por token de portador para o registro dinâmico de clientes, será necessário um token de acesso inicial.
Crie um Cliente de API com a autorização Manage OIDC client registration dynamically. Para criar o cliente da API, consulte Gerenciamento do acesso à API do aplicativo.
Depois que o Cliente da API for criado, use o fluxo client_credenciais para obter o token de acesso. O código a seguir é um exemplo:
curl -ki -v https://{{tenant}}/v1.0/endpoint/default/token -d "grant_type=client_credentials&client_id=<clientId>&client_secret=<clientSecret>"
A solicitação de registro dinâmico do cliente exige que o token de portador seja fornecido no cabeçalho de autorização.
Requerer MTLS para registro de cliente dinâmico
Se a autorização da solicitação estiver configurada para exigir certificação mútua ( TLS ), o cliente deverá apresentar um certificado válido para a solicitação.
Registrar um novo aplicativo usando a API de registro
A tabela a seguir mostra a lista de metadados do cliente que são suportados atualmente.
| Nome de metadados | Descrição de metadados | Opcional | Valores válidos |
|---|---|---|---|
| client_name | Nome do Aplicativo | true | sequência |
| ID de cliente | O ID do cliente será gerado automaticamente se ele não for fornecido. | true | sequência |
| client_secret | O segredo do cliente será gerado automaticamente se ele não for fornecido. | true | sequência |
| redirect_uris | Lista de URIs de redirecionamento. | false | Lista de URI de sequência |
| grant_types | Matriz de tipos de concessão que o aplicativo pode usar. | true | “authorization_code”, “implicit”, “password”, “refresh_token” e “client_credentials” |
| id_token_signed_response_alg | Algoritmo de assinatura de token. | true | 'RS256', 'RS384', 'RS512', 'ES256', 'ES384', 'ES512', 'PS256', 'PS384', 'PS512' |
| all_users_entitled | Configure como true se todos os usuários tiverem autorização para usar este aplicativo. | true | true ou false |
| jwks_uri | URL do documento do JSON Web Key Set do Client. | true | URL |
| consent_action | Solicitação de consentimento do usuário. | true | ‘never_prompt’ ou ‘always_prompt’ |
| enforce_pkce | Cumprir o uso do PKCE. | true | true ou false |
| Escopo | Sequência de escopos permitidos separados por espaços. | true | sequência |
| id_token_claims | Lista de solicitações para informações de id_token e do usuário. | true | Lista de sequências |
| token_claims | Lista de solicitações para introspecção e token de acesso JWT. | true | Lista de sequências |
| initiate_login_uri | A URL para iniciar o login. | true | URL |
| tipos_de_resposta | Tipos de resposta utilizados por este cliente. | true | Lista de sequências |
| token_endpoint_auth_method | Método de autenticação de cliente para o terminal de token. | true | 'default', 'client_secret_basic', 'client_secret_post', 'private_key_jwt', 'tls_client_auth' |
| tls_client_auth_subject_dn | O nome distinto esperado do certificado que o cliente utiliza na autenticação mútua TLS. | true | sequência |
| tls_client_auth_san_dns | A entrada SAN de nome DNS esperada no certificado que o cliente utiliza na autenticação mútua do protocolo TLS. | true | sequência |
| tls_client_auth_san_uri | A entrada URI SAN esperada no certificado que o cliente utiliza na autenticação mútua TLS. | true | sequência |
| tls_client_auth_san_ip | A entrada SAN com o endereço IP esperado no certificado que o cliente utiliza na autenticação mútua TLS. | true | sequência |
| tls_client_auth_san_email | A entrada SAN de endereço de e-mail esperada no certificado que o cliente utiliza na autenticação mútua TLS. | true | sequência |
| tls_client_certificate_bound_access_tokens | Indica se a ligação de certificado para o token de acesso é necessária. | true | true ou false |
| algoritmo_de_resposta_assinada_de_informações_do_usuário | O algoritmo de assinatura JWT da resposta de informações do usuário. | true | 'RS256', 'RS384', 'RS512', 'ES256', 'ES384', 'ES512', 'PS256', 'PS384', 'PS512' |
| algoritmo_de_resposta_criptografada_de_informações_do_usuário | O algoritmo de criptografia JWT da resposta de informações do usuário. | true | “RSA-OAEP”, “ RSA-OAEP-256 ” |
| resposta_criptografada_de_informações_do_usuário | O algoritmo de criptografia do conteúdo do JWT da resposta de informações do usuário. | true | 'A128GCM', 'A192GCM', 'A256GCM' |
Exemplo para registro de um novo aplicativo
O código a seguir é um exemplo de solicitação quando o registro dinâmico de clientes está configurado para exigir autorização por token de portador.
curl -ki -H "Authorization: bearer <access-token>" -H "Content-Type:application/json" -X POST https://{{tenant}}/oauth2/register --data-binary '{"redirect_uris":["https://www.redirect.com"],"client_name":"MyApplication"}'
respostas
{
"grant_types": [
"authorization_code"
],
"client_secret_expires_at": "0",
"registration_client_uri": "https://{{tenant}}/oauth2/register/<clientId>",
"client_secret": "<client_secret>",
"redirect_uris": [
"https://www.redirect.com"
],
"client_id_issued_at": "1586933118",
"client_name": "MyApplication",
"registration_access_token": "<access_token>",
"client_id": "<clientId>",
"id_token_signed_response_alg": "RS256"
}
Configuração adicional do aplicativo
Após a criação do aplicativo, é possível configurar mais opções para ele, como mapeamento de atributos, política de acesso, fontes de identidade, usuários autorizados e outras. Para configurar essas opções, consulte “Configurando o logon único no aplicativo OpenID Connect” ou “Configurando o logon único nos aplicativos OpenID Connect for Open Banking ”.
Atualizar o aplicativo OIDC usando a API de registro
O código a seguir é um exemplo de como usar o token registration_access_token obtido na etapa anterior como token de portador de autorização e enviar uma solicitação PUT para modificar o cliente. Observe que as alterações feitas na configuração do aplicativo OIDC serão substituídas.
curl -ki -H "Authorization: bearer <registration_access_token>" -H "Content-Type:application/json" -X PUT https://{{tenant}}/oauth2/register/<client-id> --data-binary '{"redirect_uris":["https://www.redirect.com/callback"],"client_name":"MyApplication2"}'
Ler aplicativo OIDC usando a API de registro
A API de registro também fornece uma maneira de ler o aplicativo OIDC novamente.
curl -ki -H "Authorization: bearer <registration-access-token>" https://{{tenant}}/oauth2/register/<clientId>
Excluir um aplicativo OIDC usando a API de registro
A API de registro também fornece uma maneira de excluir o aplicativo OIDC.
curl -ki -H "Authorization: bearer <registration-access-token>" -X DELETE https://{{tenant}}/oauth2/register/<clientId>
Token de acesso ao registro expirado
Se o token de acesso de registro expirar, obtenha um novo token de acesso usando o ID e o segredo do cliente que foi registrado. Consulte “Obter o token de acesso inicial ”.