TsgcHTTP_OAuth2_Client

Este componente permite que você gerencie o fluxo entre o cliente e os outros papéis. Basicamente, quando você define Active := True, ele abre um novo navegador web e solicita ao usuário a concessão de autorização; se bem-sucedido, o servidor de autorização envia um token à aplicação, que é processado e, com este token, o cliente pode se conectar ao servidor de recursos. Este componente inicia um servidor HTTP simples que trata as respostas do servidor de autorização e usa um cliente HTTP para solicitar Access Tokens.

 

GrantType

 

O cliente suporta os seguintes tipos de autorização:

 

auth2Code: É utilizado para realizar autenticação e autorização na maioria dos tipos de aplicações, incluindo aplicações de página única, aplicações web e aplicações instaladas nativamente. O fluxo permite que as aplicações adquiram com segurança access_tokens que podem ser utilizados para acessar recursos protegidos, bem como refresh tokens para obter access_tokens adicionais, e ID tokens para o usuário autenticado.

 

 

auth2CodePKCE: é o mesmo fluxo de autenticação que auth2Code com PKCE habilitado. PKCE (Proof Key for Code Exchange) é uma extensão de segurança para OAuth 2.0, projetada para aprimorar a segurança de fluxos de autorização para aplicações nativas e single-page. Ele mitiga o risco de ataques de interceptação, especialmente em clientes públicos onde o authorization code pode ser exposto a interceptação em trânsito. Geralmente esta opção é utilizada em apps nativos e mobile.

 

auth2ClientCredentials: Este tipo de grant é comumente utilizado para interações servidor-a-servidor que devem ser executadas em segundo plano, sem interação imediata com um usuário. Esses tipos de aplicações são frequentemente chamados de daemons ou contas de serviço.

 

 

auth2DeviceCode: Device Authorization Grant (RFC 8628) para dispositivos com entrada limitada, como smart TVs, consoles de mídia e dispositivos IoT que não possuem navegador ou têm capacidades de entrada limitadas. O dispositivo exibe um código de usuário e uma URI de verificação; o usuário visita a URI em um dispositivo secundário (celular ou computador) e insere o código para autorizar.

 

LocalServerOptions

 

Quando um cliente precisa de um novo Access Token, ele inicia automaticamente um servidor HTTP para processar a resposta do servidor de autorização. Este servidor é transparente para o usuário e geralmente funciona em localhost. Por padrão utiliza a porta 8080, mas você pode alterar se necessário.

 

• IP: IP no qual o servidor escuta, exemplo: 127.0.0.1
• Port: por padrão 8080. Ao usar GrantType = auth2CodePKCE (para aplicações desktop e nativas), você pode definir o valor da porta como zero e o servidor escolherá uma porta aleatória.
• RedirectURL: (opcional) permite personalizar a redirect URL, exemplo: http://localhost:8080/oauth/.
• SSL: habilite esta propriedade se o servidor local rodar em uma porta segura (*suportado somente pelas edições Professional e Enterprise).
• SSLOptions: permite personalizar as propriedades SSL do servidor (*suportado somente pelas Edições Professional e Enterprise).
• LogOptions: permite salvar o log das requisições/respostas recebidas e enviadas pelo HTTP Internal Server (*Apenas para as edições Professional e Enterprise).
  • Enabled: defina como True para habilitar o log em arquivo.
  • FileName: defina o nome do arquivo para armazenar o arquivo de log.

 

AuthorizationServerOptions

 

Aqui você deve definir a URL para Authorization e Access Token, normalmente fornecidas na especificação da API. Scope é uma lista de todos os escopos solicitados pelo cliente. Exemplo:

 

• AuthURL: https://accounts.google.com/o/oauth2/auth
• TokenURL: https://accounts.google.com/o/oauth2/token
• Scope: https://mail.google.com/
• RevocationURL: URL para o endpoint de revogação de token (obrigatório para o método Revoke). Exemplo: https://accounts.google.com/o/oauth2/revoke
• IntrospectionURL: URL do endpoint de introspecção de token (obrigatório para o método Introspect). Exemplo: https://accounts.google.com/o/oauth2/introspect

 

OAuth2Options

 

ClientId é um campo obrigatório que informa ao servidor qual é a identificação do cliente. Verifique a especificação da sua API para saber como obter um ClientId. O mesmo se aplica ao client secret.

Às vezes, o servidor exige um usuário e uma senha para conectar usando Basic Authentication; se for o caso, você pode configurar isso nos campos Username/Password. Exemplo:

 

• GrantType: Tipo de fluxo de autorização
  • auth2Code: aplicações confiáveis, como um web-server.
  • auth2CodePKCE: aplicações nativas ou móveis não confiáveis.
  • auth2ClientCredentials: aplicações automatizadas sem interação do usuário.
  • auth2ResourceOwnerPassword: permite que uma aplicação autentique o usuário tratando diretamente sua senha
  • auth2DeviceCode: Device Authorization Grant (RFC 8628) para dispositivos com restrições de entrada, sem navegador ou com capacidades de entrada limitadas.
• ClientId: 180803918307-eqjtm20gqfhcs6gjklbbrreng022mqqc.apps.googleusercontent.com
• ClientSecret: _by1iYYrvVHxC2Z8TbtNEYJN
• Username:
• Password:

 

HTTPClientOptions

 

Aqui você pode personalizar as Opções do Cliente quando ele se conecta ao Servidor HTTP para solicitar um novo token.

 

TLSOptions: se o TLS estiver habilitado, aqui você pode personalizar algumas propriedades TLS.

 

ALPNProtocols: lista dos protocolos ALPN que serão enviados ao servidor.

RootCertFile: caminho para o arquivo de certificado raiz.

CertFile: caminho para o arquivo de certificado.

KeyFile: caminho para o arquivo de chave do certificado.

Password: se o certificado está protegido com uma senha, defina-a aqui.

VerifyCertificate: se o certificado deve ser verificado, habilite esta propriedade.

VerifyDepth: é uma propriedade Integer que representa o número máximo de links permitidos quando a verificação é realizada para o certificado X.509.

Version: por padrão usa TLS 1.0; se o servidor exigir uma versão TLS superior, ela pode ser selecionada aqui.

IOHandler: selecione qual biblioteca você utilizará para conectar usando TLS.

iohOpenSSL: utiliza a biblioteca OpenSSL e é o padrão para componentes Indy. Requer implantar as bibliotecas openssl para win32/win64.

iohSChannel: utiliza o Secure Channel, que é um protocolo de segurança implementado pela Microsoft para Windows, não requer a implantação de bibliotecas openssl. Funciona apenas no Windows 32/64 bits.

OpenSSL_Options: permite definir qual API OpenSSL será utilizada.

APIVersion: permite definir qual API OpenSSL será usada.

oslAPI_1_0: usa a API 1.0 do OpenSSL, é a mais recente suportada pelo Indy

oslAPI_1_1: usa a API 1.1 do OpenSSL, requer nossa biblioteca Indy personalizada e permite usar as bibliotecas OpenSSL 1.1.1 (com suporte a TLS 1.3).

oslAPI_3_0: utiliza a API 3.0 do OpenSSL, requer nossa biblioteca Indy personalizada e permite utilizar as bibliotecas OpenSSL 3.0.0 (com suporte a TLS 1.3).

LibPath: aqui você pode configurar onde estão localizadas as bibliotecas openSSL

oslpNone: este é o padrão, as bibliotecas openSSL devem estar na mesma pasta onde está o binário ou em um caminho conhecido.

oslpDefaultFolder: define automaticamente o caminho openSSL onde as bibliotecas devem estar localizadas para todas as personalidades do IDE.

oslpCustomFolder: se esta for a opção selecionada, defina o caminho completo na propriedade LibPathCustom.

LibPathCustom: quando LibPath = oslpCustomFolder, defina aqui o caminho completo onde estão localizadas as bibliotecas openSSL.

UnixSymLinks: habilita ou desabilita o carregamento de SymLinks em sistemas Unix (por padrão está habilitado, exceto no OSX64):

oslsSymLinksDefault: por padrão estão habilitados, exceto sob OSX64 (após o MacOS Monterey falha ao tentar carregar a biblioteca sem versão.).

oslsSymLinksLoadFirst: Carrega os SymLinks e faz isso antes de tentar carregar as bibliotecas de versão.

oslsSymLinksLoad: Carrega os SymLinks após tentar carregar as bibliotecas de versão.

oslsSymLinksDontLoad: não carrega os SymLinks.

SChannel_Options: permite que você utilize um certificado do Windows Certificate Store.

CertHash: é o Hash do certificado. Você pode encontrar o Hash do certificado executando um comando dir no powershell.

CertStoreName: o nome do store onde o certificado está armazenado. Selecione um dos abaixo:

scsnMY (o padrão)

scsnCA

scsnRoot

scsnTrust

CertStorePath: o caminho do store onde o certificado está armazenado. Selecione um dos abaixo:

scspStoreCurrentUser (o padrão)

scspStoreLocalMachine

 

LogOptions: se um nome de arquivo for definido, salvará um log das requisições/respostas HTTP do cliente HTTP