[PHP] Access token als header mee geven ipv in querystring

[GWTommy]

Ik ben bezig met een API die lijkt op de Facebook Graph API, qua URI structuur, etc. Dit is voor een iOS app, die gaat de data consumeren en manipuleren via de API.

Voor de beveiliging had ik zoiets in gedachte:
http://www.thebuzzmedia.c...out-oauth-authentication/

Vrij simpel te implementeren en moet niet al te veel ballast met zich mee brengen. Nou was ik dus van plan om de access token en overige velden ter authenicatie in de query string mee te geven, zoals Facebook met z'n access_token parameter. Echter ben ik van plan om ook andere parameters op deze manier mee te geven, waaronder bijvoorbeeld een 'fields' parameter zoals Facebook dat ook doet. Het leek mij daarom echter handiger, ofja, netter, om de velden als access token, signature, timestamp, als HTTP header mee te geven in plaats van in de query string. Ik snap dat Facebook dit niet doet omdat het voor de gebruikers makkelijker is om het in de query string te doen. Gezien ik de enige ben die gebruik maakt van de API denk ik hier natuurlijk anders over.

Zie ik iets over het hoofd om dit sowieso niet te doen? Ben benieuwd wat jullie kijk hierop is.

Edit: nu pas zie ik dat mijn PHP tag in de titel eigenlijk niet zo handig is. De API wordt geschreven in PHP, maar goed voor dit 'probleem' doet dat er vrij weinig toe.

[ Voor 6% gewijzigd door GWTommy op 22-06-2013 19:11 ]

[DexterDee]

In principe is er niks op tegen om diverse velden via een HTTP header mee te sturen, je doet niks dat buiten de HTTP specificaties valt. Voor een publieke API zou ik het niet aanraden, omdat het de uitwisseling een stuk moeilijker maakt en de API dan niet meer zo makkelijk te testen is in een browser.

Aangezien het een API betreft die voor één specifiek doel gemaakt is, maakt het mijn inziens niet echt uit of het request er "netjes" uitziet. Het is toch uiteindelijk verkeer tussen twee computersystemen en die hebben over het algemeen geen esthetische voorkeur

Voornaamste is dat jij als programmeur een API maakt die zo simpel mogelijk in gebruik is, zonder afbreuk te doen aan functionaliteit, onderhoudbaarheid en performance. Persoonlijk zou ik om bovengenoemde reden (lastiger testen) geen headers gebruiken om informatie door te sturen. Ik zie echter geen redenen waarom het technisch niet zou kunnen werken.

Enige technische beperkingen wil ik je nog wel meegeven over het gebruik van HTTP headers. Verschillende webserver hanteren verschillende limieten. In Apache mag de header maximaal 8KB zijn, in IIS is dit 16KB. Hierboven zal de webserver het request afwijzen. De query string wordt overigens ook in de header meegestuurd, dus daar gelden dezelfde limieten voor. Voor het doorgeven van grote hoeveelheden data zou ik persoonlijk altijd een x-www-form-urlencoded POST request doen.

Er zit overigens nog wel een voordeeltje aan het gebruiken van HTTP headers, mits je in de body niks meestuurt. Door een HEAD request te doen in plaats van een GET / POST, kun je alléén de headers opvragen. Scheelt weer een heel klein beetje performance

[Pizzalucht]

In de oAuth 2 specificatie zit ondersteuning voor het gebruiken van de header voor authenticatie:

http://self-issued.info/d...arer.html#rfc.section.2.1

Oh, ik lees nu de link, je wilt geen oAuth gebruiken.
Als je toch iets zelf gaat verzinnen, dan maakt het toch niet uit wat je gebruikt?

[ Voor 28% gewijzigd door Pizzalucht op 22-06-2013 21:11 ]

[Gomez12]

iOS app als in ook mobile ondersteuning?

Want dan zou ik afstappen van custom headers en gewoon standaard post gebruiken.
Er zijn nog steeds veel mobiele providers die data via een proxy versturen en die proxy's willen wel eens rare geintjes uithalen met je requests. En dat kan met custom headers wel eens een ramp worden om te debuggen.

[Cartman!]

Ik zou in de headers geen parameters neerzetten die betrekking hebben op de functie die je wilt uitvoeren, enkel parameters die globaal bedoelt zijn voor de achterliggende REST service (accesstoken, consumer, versienummers etc).

[Barryvdh]

Wat eigenlijk ook een beetje de conclusie van die post is, is dat je net zo goed gewoon OAuth1 kan gebruiken dan hè. Volgens mij staat in die documentatie ook dat je die headers kan gebruiken.
Hier bijv een php implementatie volgens de standaard en met composer: https://github.com/joakimkejser/OAuth

[drm]

Een groot voordeel van de querystring is dat het makkelijk loggen is. Je kunt dat dan gewoon aan standaard webserver logging overlaten. Verder kun je een request makkelijk fingeren door 'm in je browser te openen of te wgetten/curlen in je terminal. Dat is ook direct een (het) nadeel van querystrings gebruiken voor authenticatie: het is makkelijk te reproduceren: een ieder die de link in handen krijgt kan hem ook openen. Als dat een acceptabel of verwaarloosbaar risico is dan is een querystring vele malen eenvoudiger, al is het alleen al omdat het samenstellen en het uitlezen van een request gewoon veel makkelijker is.

[Barryvdh]

Als je net als in OAuth (of die blogpost) je queries beveiligd met een api key/secret en alle hashes maar eenmalig gebruit kunnen worden, kan je niet zomaar nogmaals die url aanroepen.