Det skickas som en helt vanlig http auth.
Här står det lite om auth: http://httpd.apache.org/docs/2.0/howto/htaccess.html

edit: Och här står lite om att använda php till authen: http://us3.php.net/manual/en/features.http-auth.php

Om man sätter kravet GET så är det crazzy säger säkrast, eller i alla fall någonting som går i någon header, att sätta en cookie skulle säkert fungera lika bra det med. Det som är viktigt att tänka på är att allt som följer med i url:en kan loggas, t.ex. på webbservern, en proxy, någon mystisk brandvägg etc. Beroende på config med certifikat etc. så ger inte ssl något skydd mot sådan loggning. (POST klarar sig bättre där..)

Det är bättre att använda engångsnycklar, ett exempel:
Klienten skickar UserID + hashsumman SHA1(hemlignyckel+salt) , servern läser UserID och verifierar sen hashsumman på samma sätt. Den hemliga nyckeln behöver då aldrig skickas över nätet. Saltet kan bestå av dagens datum. Om nån avlyssnar får dom bara en kod som fungerar en kort tid.

Det som Jine skickade först är HTTP AUTH, och lägger sig under "$_SERVER" i PHP, tror det är HTTP_AUTH_USER & HTTP_AUTH_PASS. Men det skickas i klartext här med.

Det bästa är nog att skicka ut User, Pass + unikt SALT och kräva att det saltas med tex. datumet.

Tex. sha1(USERNAME + SALT + DATUM + PASS)

att blanda in HTTPS här är nog bara overkill.

Nej, det skickas inte i klartext om HTTPS är inblandat?
Precis det som var poängen.

Säkrast för GET är:
* HTTPS
* HTTP Auth/Cookie/etc med någon "apinyckel" skiljd från inloggningsuppgifter (vid ev. intrång på klient-sidan så är det bara api:t man kommer åt, man kommer inte längre)
* Ingenting i URL:en eftersom att det troligtvis fastnar i någon rolig logg någonstans, vilket minskar säkerheten lite eftersom att nyckel/inloggningsuppgifter fastnar där "permanent". Förslagsvis är nyckeln hashad i databasen så ev. läsning i databasen ger ingen nyckel. Men om man även kan få tag på loggen så..

Om man vill skicka nyckeln hashad (t.ex. sha1(datum + nyckel)) måste man väl spara den i klartext på serversidan. Finns det några bra sätt att skydda nyckeln på serversidan? Det går ju att få lite extra skydd genom att spara den krypterad i databasen och ha en statisk nyckel i skriptet, men frågan är om det är värt besväret.

I det här fallet bör man nog skapa en nyckel automatiskt, och inte låta användaren ändra nyckel på annat sätt än att skapa en ny slumpmässig nyckel. Detta för att dels få en stark nyckel, och dels för att skydda användaren; det är inte möjligt att ange en nyckel (som sparas i klartext hos både klienten och servern) som användaren använder på något annat ställe. Denna nyckel används enbart för api. För vanlig inloggning används ett annat lösenord på vanligt sätt.

Om man använder datum som salt, tänk på att klienten och servern ska ange datumet enligt samma tidszon.

Vad sägs om en lösning i stil med följande?
$salt=round(timestamp/100);
User-id samt sha1($salt + nyckel) skickas som http auth.

Det kräver att klockorna på båda sidor går någorlunda rätt. För ökad säkerhet, dela med 10 istället om man är säker på att klockorna går nästan exakt rätt.

Servern kontrollerar:
$salt=round(timestamp/100);
if($http_pass==sha1($salt + nyckel) || $http_pass==sha1(($salt+1) + nyckel) || $http_pass==sha1(($salt-1) + nyckel))

Alternativ:
Använd hela timestamp som salt. Skicka med även salt i requesten (tillsammans med user-id och hash). Servern kontrollerar att salt inte skiljer sig för mycket från aktuell timestamp.

Krypterad nyckel / hash som dels är baserad på användarens tillåtna IP/IP-range och lösen + salt.
Då kan nyckeln komma på vift utan att den kan användas. Sen kan man även langa in en datumrestricter så nyckeln enbart fungerar i X-antal dagar.

Stort tack för alla förslag, fortsätt gärna, bra för andra också.

Jag ska fundera över vad som blir bäst för detta.

Mja, alltså, det är något sådant jag tänker. Nyckeln ska vara slumpmässig, skulle användaren tappa bort sin nyckel så genererar man bara en ny. Nyckeln bör vara sparad hashad på servern.

Att börja greja med datum och hasha en nyckel känns overkill, man kommer fortfarande inte ifrån problemet med att nyckeln finns fullt läsbar i klienten. Om man skyddar själva överföringen mellan klient och server med SSL så fyller ett sådant hash ingen funktion.

Däremot, om man inte nyttjar SSL så kan det finnas en poäng med hashad nyckel. Det skyddar dock bara mot framtida attacker, en attack som man-in-the-middle är dock fortfarande utsatt - bara att ändra innehållet on-the-fly. (Även om det går att skaffa sig skydd där också: signera all data som skickas över med nyckel + datum, kontrollera på servern..)

Personligen så tror jag dock att det inte är så realistiskt att man kan räkna med att klockorna går särskilt rätt i båda ändarna..

Kan man köra med SSL så fixar man många problem :)