Pré-requisitos para consumir o endpoint token

• Uma aplicação devidamente configurada
• Usuário valido
• Credenciais de um client valido
• JWKs configurada para geração do access_token
• Verificar os métodos de autenticação validos
• Valor "code" retornado pelo endpoint authorize

Endpoint de configurações

URL de Documentação da API : /apidocs/#/OAuth2/get__application__oauth__well_known_oauth_authorization_server

O endpoint .well-know informa ao cliente de forma dinamica quais endpoints devem ser utilizados para a integração, não sendo nescessario uma configuração manual dos endpoints.

curl -X GET "https://[ip ou hostname (fqdn)]/<application name>/oauth/.well-known/oauth-authorization-server" \
-H "accept: application/json"

Exemplo de resposta do endpoint:

{
  "authorization_endpoint": "https://[ip ou hostname (fqdn)]/<application name>/oauth/authorize",
  "grant_types_supported": [
    "authorization_code"
  ],
  "issuer": "<issuer>",
  "jwks_uri": "https://[ip ou hostname (fqdn)]/<application name>/oauth/jwks",
  "mtls_endpoint_aliases": {},
  "registration_endpoint": "https://[ip ou hostname (fqdn)]/<application name>/oauth/dcr",
  "response_types_supported": [
    "code"
  ],
  "revocation_endpoint": "https://[ip ou hostname (fqdn)]/<application name>/oauth/revoke",
  "scopes_supported": [
    "email",
    "profile"
  ],
  "tls_client_certificate_bound_access_token": true,
  "token_endpoint": "https://[ip ou hostname (fqdn)]/<application name>/oauth/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_post"
  ],
  "token_endpoint_auth_signing_alg_values_supported": [
    "RS256"
  ],
  "userinfo_endpoint": "https://[ip ou hostname (fqdn)]/<application name>/oauth/userinfo"
}

Authorize

URL de Documentação da API : /apidocs/#/OAuth2/get__application__oauth_authorize

A chamada deve ser feita direto na barra de busca/url do navegador

Parâmetros:

• application:
  • Obrigatório: Sim
  • Tipo: String
  • Localização: Caminho da URL (Path)
  • Descrição: Nome da aplicação a ser usada.
• client_id:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: ID do cliente a ser usado no fluxo
• scope:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: Quais escopos seram adicionados no access_token (iram refletir também no retorno dos dados do usuario no endpoint userinfo)
• response_type:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: Qual o padrão de resposta que o IDP deve responder [code, token, id_token, ...]
• redirect_uri:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: Qual o caminho/endpoint que o IDP deve enviar a resposta
• nonce:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: Preenchido somente se o parametro nonce estiver habilitado na aplicação
• code_challenge:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: Preenchido somente se o parametro PKCE estiver habilitado na aplicação
• code_challenge_method:
  • Tipo: String
  • Localização: Caminho da URL (Path).
  • Descrição: Preenchido somente se o parametro PKCE estiver habilitado na aplicação

Exemplos:

• URL:

    https://[ip ou hostname (fqdn)]/<application name>/oauth/authorize?client_id=<client id>&scope=<all or a spefic one>&response_type=<response type configured>&redirect_uri=<redirect uri>
  

Pré-requisitos para autenticação via TLS mútuo (mTLS)

Configurando NGINX para conexões HTTPS

A seguir iremos configurar o NGINX para realizar conexões seguras via HTTPS, partiremos da premissa que o NGINX já esteja instalado, e que a pasta nginx/sites-available e o arquivo nginx/sites-available/default estejam presentes no sistema.

• Observação: O uso do Nginx no contexto desta documentação visa apenas exemplificar um servidor web com as configurações necessárias para proxy reverso com HTTPS configurado, qualquer outro servidor web que atenda os mesmos requisitos também pode ser usado.

  • Configurando o arquivo nginx/sites-available/default

  • Navegar até a pasta nginx/sites-available

    cd /etc/nginx/sites-available
    

  • Abrir o arquivo default em algum editor de texto

    # Obs: talvez seja necessário abrir o arquivo em modo administrador
    sudo vi default
    

  • Exemplo de configuração para habilitar conexões HTTPS

    server {
     listen 80;
     return 302 https://$host$request_uri;
    }
    server {
    
           listen 443 ssl default_server;
           listen [::]:443 ssl default_server;
    
           server_name <your_server_name>;
    
           ssl_certificate        /etc/nginx/certs/server.chained.cert.pem;
           ssl_certificate_key    /etc/nginx/certs/server.key.pem;
           ssl_protocols          TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;     
           ssl_verify_client      optional_no_ca;
           ssl_session_cache      shared:SSL:10;
    
          location / {
                  proxy_set_header Host $host
                  proxy_set_header X-Client-Cert $ssl_client_cert;
                  proxy_pass http://[ip ou hostname (fqdn)];
          }
    }
    

    • Observações
      
    • Caso não tenha certificados emitidos por uma CA (Certificate Authority), a seção Certificados digitais contém informações sobre como gerar seu próprio certificado.
    • No exemplo acima, a diretiva ssl_certificate é configurada a partir da concatenação dos dos certificados root CA e intermediate CA configurados na seção Certificados Digitais. Referência: SSL certificate chains
      

  • Testar e atualizar as configurações.

    • Verificar se há algum erro nas configurações

      ngxin -t
      

    • Atualizar as configurações

      nginx -s reload
      

Certificados digitais

Esta seção contém uma breve descrição da documentação da OpenSSL CA, uma biblioteca com utilitários criptográficos que nos permite lidar com certificados digitais. Aqui utilizaremos a biblioteca para agir como uma autoridade de certificação e emitirmos nossos próprios certificados públicos autenticados.

1. Criação do par chave/certificado raíz

• Referência: Create the Root Pair
• Aqui deve ser criado o certificado raíz, que em conjunto com o intermediário irá realizar assinatura dos certificados do server e do client. O certificado raíz não assina outros certificados diretamente, ele é usado apenas como media de segurança, uma vez que, idealmente, ele é armazenado em um ambiente com pouca exposição.

  2. Criação do par chave/certificado intermediário

• Referência: Create the Intermediate Pair
• Nesta etapa espera-se que seja criado o certificado intermediário, este que realizará de fato as assinaturas de outros certificados em nome do certificado raíz. Os dois certificados, raíz e intermediário, posteriormente serão registrados nas configurações da aplicação. A seção Configurando a aplicação contém mais detalhes a respeito desse processo

  3. Criação e assinatura dos certificados

• Referência: Sign Server and Client Certificates
• Por fim, deve-se criar os certificados do server que serão utilizados para realizar conexões seguras, e o certificado do client que posteriormente será usado para autentica-lo com o método TLS CLIENT AUTH

Configurando a aplicação

TLS Trusted Certificates

• Nessse campo deve-se colocar os certificados raíz e intermediário criados na seção Certificads Digitais

  1. Concatenamos o conteúdo dos dois arquivos em um único arquivo

     cat ca.cert.pem intermediate.cert.pem > ca+intermediate.pem
     

  2. Em seguida, basta colar o conteúdo do arquivo ca+intermediate.pem no campo TLS Trusted Certificates

  MTLS Endpoint Aliases (URL)

• Nesses campos deve-se colocar os endpoints que estão configurados para receber conexões via mTLS. A seção Configurando NGINX para conexões HTTPS tratou do assunto.

  TLS Client Certificate Header Name

  

  TLS Client Certificate-Bound Access-Token

  

  • Ativar essa opção é muito importante pois dessa maneira o server de autorização consegue vincular o access_token ao certificado do cliente. Referência: Mutual-TLS Client Certificate-Bound Access Tokens