HTTP básico e autenticação de token do portador

Atualmente, estou desenvolvendo uma REST-API que é protegida por HTTP-Basic para o ambiente de desenvolvimento. Como a autenticação real é feita por meio de um token, ainda estou tentando descobrir como enviar dois cabeçalhos de autorização.

Eu tentei este:

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

Eu poderia, por exemplo, desabilitar a autenticação HTTP para o meu IP, mas como costumo trabalhar em diferentes ambientes com IPs dinâmicos, esta não é uma boa solução. Então, estou perdendo alguma coisa?

Tente este para enviar autenticação básica no url:

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

Se um acima não funcionar, você não tem nada a ver com isso. Portanto, tente as alternativas a seguir.

Você pode passar o token com outro nome. Porque você está lidando com a autorização de seu aplicativo. Portanto, você pode usar facilmente essa flexibilidade para esse propósito especial.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

Observe que mudei o cabeçalho para Application-Authorization. Portanto, em seu aplicativo, pegue o token sob esse cabeçalho e processe o que você precisa fazer.

Outra coisa que você pode fazer é passar tokenos POSTparâmetros e obter o valor do parâmetro do lado do servidor. Por exemplo, passando o token com o parâmetro curl post:

-d "auth-token=mytoken123"

Padrão ( https://tools.ietf.org/html/rfc6750 ) diz que você pode usar:

• Parâmetro do corpo codificado em formulário: Autorização: Bearer mytoken123
• Parâmetro de consulta de URI: access_token = mytoken123

Portanto, é possível passar muitos Bearer Token com URI, mas isso é desencorajado (consulte a seção 5 do padrão).

Se estiver usando um proxy reverso, como nginx, você poderá definir um token personalizado, como X-API-Token.

No nginx, você o reescreveria para o proxy upstream (sua API restante) para ser apenas auth:

proxy_set_header Authorization $http_x_api_token;

... enquanto nginx pode usar o cabeçalho de autorização original para verificar HTTP AUth.

Eu tive um problema semelhante - autenticar o dispositivo e o usuário no dispositivo. Usei um Cookiecabeçalho ao lado de um Authorization: Bearer...cabeçalho.

curl --anyauth

Diz ao curl para descobrir o método de autenticação por si mesmo e usar o mais seguro que o site remoto afirma oferecer. Isso é feito primeiro fazendo uma solicitação e verificando os cabeçalhos de resposta, possivelmente induzindo uma viagem extra de ida e volta da rede. Isso é usado em vez de definir um método de autenticação específico, que você pode fazer com --basic, --digest, --ntlm e --negotiate.

Existe outra solução para testar APIs no servidor de desenvolvimento.

• Definido HTTP Basic Authenticationapenas para rotas da web
• Deixe todas as rotas de API livres de autenticação

A configuração do servidor da Web para nginxe Laravelseria assim:

    location /api {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;

        auth_basic "Enter password";
        auth_basic_user_file /path/to/.htpasswd;
    }

Authorization: Bearer fará o trabalho de defender o servidor de desenvolvimento contra rastreadores da web e outros visitantes indesejados.

Com o nginx, você pode enviar os dois tokens assim (mesmo que seja contra o padrão):

Authorization: Basic basic-token,Bearer bearer-token

Isso funciona desde que o token básico seja o primeiro - o nginx o encaminha com êxito para o servidor de aplicativos.

E então você precisa ter certeza de que seu aplicativo pode extrair corretamente o portador da string acima.