HTTP di base e autenticazione del token di portatore

Attualmente sto sviluppando un'API REST che è protetta da HTTP di base per l'ambiente di sviluppo. Poiché la vera autenticazione viene eseguita tramite un token, sto ancora cercando di capire come inviare due intestazioni di autorizzazione.

Ho provato questo:

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

Ad esempio, potrei disabilitare l'autenticazione HTTP per il mio IP ma poiché di solito lavoro in ambienti diversi con IP dinamici, questa non è una buona soluzione. Quindi mi sto perdendo qualcosa?

Prova questo per eseguire il push dell'autenticazione di base all'URL:

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

Se uno sopra non funziona, non hai niente a che fare con esso. Quindi prova le seguenti alternative.

Puoi passare il token con un altro nome. Perché stai gestendo l'autorizzazione dalla tua applicazione. Quindi puoi facilmente utilizzare questa flessibilità per questo scopo speciale.

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

Notare che ho cambiato l'intestazione in Application-Authorization. Quindi dalla tua applicazione prendi il token sotto quell'intestazione ed elabora ciò che devi fare.

Un'altra cosa che puoi fare è passare tokenattraverso i POSTparametri e prendere il valore del parametro dal lato Server. Ad esempio, passando il token con il parametro curl post:

-d "auth-token=mytoken123"

Standard ( https://tools.ietf.org/html/rfc6750 ) dice che puoi usare:

• Parametro del corpo con codifica in forma: Autorizzazione: Bearer mytoken123
• Parametro query URI: access_token = mytoken123

Quindi è possibile passare molti Bearer Token con URI, ma è sconsigliato farlo (vedere la sezione 5 dello standard).

Se stai utilizzando un proxy inverso come nginx in mezzo, puoi definire un token personalizzato, come X-API-Token.

In nginx dovresti riscriverlo per il proxy upstream (la tua rest api) per essere solo auth:

proxy_set_header Authorization $http_x_api_token;

... mentre nginx può utilizzare l'intestazione di autorizzazione originale per controllare HTTP AUth.

Ho avuto un problema simile: autenticare il dispositivo e l'utente sul dispositivo. Ho usato Cookieun'intestazione accanto a Authorization: Bearer...un'intestazione.

curl - qualunque

Indica a curl di capire da solo il metodo di autenticazione e di utilizzare quello più sicuro che il sito remoto dichiara di supportare. Questo viene fatto eseguendo prima una richiesta e controllando le intestazioni di risposta, inducendo così probabilmente un round trip di rete aggiuntivo. Viene usato invece di impostare un metodo di autenticazione specifico, che puoi fare con --basic, --digest, --ntlm e --negotiate.

Esiste un'altra soluzione per testare le API sul server di sviluppo.

• Impostato HTTP Basic Authenticationsolo per percorsi web
• Lascia tutte le route API libere dall'autenticazione

Configurazione del server Web per nginxe Laravelsarebbe così:

    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à il lavoro di difendere il server di sviluppo da crawler web e altri visitatori indesiderati.

Con nginx puoi inviare entrambi i token in questo modo (anche se è contro lo standard):

Authorization: Basic basic-token,Bearer bearer-token

Questo funziona finché il token di base è il primo: nginx lo inoltra correttamente al server delle applicazioni.

E poi devi assicurarti che la tua applicazione possa estrarre correttamente il Bearer dalla stringa sopra.