Inleiding
Token-gebaseerde authenticatie is tegenwoordig overal op het web prominent aanwezig. Met de meeste webbedrijven die een API gebruiken, zijn tokens de beste manier om authenticatie voor meerdere gebruikers af te handelen.
er zijn een aantal zeer belangrijke factoren bij het kiezen van token-gebaseerde authenticatie voor uw toepassing. De belangrijkste redenen voor tokens zijn:
- Stateless en scalable servers
- Mobile application ready
- authenticatie doorgeven aan andere applicaties
- Extra beveiliging
Wie gebruikt Token-Based authenticatie?
elke belangrijke API of webtoepassing die u tegenkomt heeft waarschijnlijk tokens gebruikt. Toepassingen zoals Facebook, Twitter, Google+, GitHub, en nog veel meer gebruik tokens.
laten we eens kijken hoe het precies werkt.
waarom Tokens Rondkwamen
voordat we kunnen zien hoe op tokens gebaseerde authenticatie werkt en de voordelen ervan, moeten we kijken naar de manier waarop authenticatie in het verleden is gedaan.
server-gebaseerde authenticatie (de traditionele methode)
aangezien het HTTP-protocol staatloos is, betekent dit dat als we een gebruiker authenticeren met een gebruikersnaam en wachtwoord, dan bij het volgende verzoek, onze toepassing niet zal weten wie we zijn. We zouden opnieuw moeten authenticeren.
de traditionele manier om onze applicaties te laten onthouden wie we zijn, is om de ingelogde informatie van de gebruiker op de server op te slaan. Dit kan op een paar verschillende manieren op de sessie worden gedaan, meestal in het geheugen of opgeslagen op de schijf.
naarmate het web, de toepassingen en de opkomst van de mobiele applicatie zijn ontstaan, heeft deze authenticatiemethode problemen laten zien, vooral op het gebied van schaalbaarheid.
de problemen met server-gebaseerde authenticatie
enkele belangrijke problemen deden zich voor met deze methode van authenticatie.
- sessies: Elke keer dat een gebruiker wordt geverifieerd, moet de server ergens op onze server een record aanmaken. Dit wordt meestal gedaan in het geheugen en wanneer er veel gebruikers authenticatie, de overhead op uw server toeneemt.
- schaalbaarheid: omdat sessies in het geheugen worden opgeslagen, levert dit problemen op met schaalbaarheid. Als onze cloudproviders beginnen met het repliceren van servers om applicatiebelasting af te handelen, zal het hebben van essentiële informatie in het sessiegeheugen ons vermogen om te schalen beperken.
- CORS: Omdat we onze applicatie willen uitbreiden zodat onze gegevens op meerdere mobiele apparaten kunnen worden gebruikt, moeten we ons zorgen maken over cross-origin resource sharing (CORS). Bij het gebruik van Ajax-oproepen om middelen van een ander domein te grijpen (mobiel naar onze API-server), kunnen we in problemen komen met verboden Verzoeken.
- CSRF: we hebben ook bescherming tegen cross-site request forgery (CSRF). Gebruikers zijn gevoelig voor CSRF-aanvallen, omdat ze al kunnen worden geverifieerd met zeggen een bank site en dit kan worden gebruikt bij het bezoeken van andere sites.
met deze problemen, waarbij schaalbaarheid de belangrijkste was, was het zinvol om een andere aanpak te proberen.
Hoe werkt Token-gebaseerde authenticatie
Token-gebaseerde authenticatie is stateloos. We slaan geen informatie over onze gebruiker op op de server of in een sessie.
dit concept alleen al lost veel problemen op met het opslaan van informatie op de server.
geen sessie-informatie betekent dat uw applicatie kan schalen en meer machines kan toevoegen zonder zich zorgen te maken over waar een gebruiker is ingelogd.
hoewel deze implementatie kan variëren, is de kern ervan als volgt::
- gebruikers Verzoeken toegang met Gebruikersnaam / Wachtwoord
- toepassing valideert referenties
- toepassing geeft een ondertekend token aan de client
- Client slaat dat token op en stuurt het samen met elk verzoek
- Server verifieert token en antwoordt met gegevens
elk verzoek vereist het token. Dit token moet worden verzonden in de HTTP header, zodat we houden met het idee van stateless HTTP requests. We zullen onze server ook moeten instellen om verzoeken van alle domeinen te accepteren met Access-Control-Allow-Origin: *. Wat interessant is aan het aanwijzen van * in de Acao header is dat het niet toestaat dat aanvragen referenties zoals HTTP authenticatie, client-side SSL certificaten of cookies leveren.
zodra we onze informatie hebben geverifieerd en we onze token hebben, zijn we in staat om veel dingen te doen met deze token.
we kunnen zelfs een op toestemming gebaseerde token maken en deze doorgeven aan een applicatie van derden (bijvoorbeeld een nieuwe mobiele app die we willen gebruiken), en ze zullen toegang hebben tot onze gegevens-maar alleen de informatie die we hebben toegestaan met dat specifieke token.
de voordelen van Tokens
Stateless en Scalable
Tokens worden opgeslagen op de client-side. Helemaal staatloos en klaar om geschaald te worden. Onze load balancers zijn in staat om een gebruiker door te geven aan een van onze servers, omdat er nergens staat of sessie informatie.
als we sessie-informatie zouden bewaren over een gebruiker die is aangemeld, zou dit vereisen dat we die gebruiker blijven sturen naar dezelfde server waarop ze zijn aangemeld (genaamd session affinity).
dit brengt problemen met zich mee omdat sommige gebruikers naar dezelfde server zouden worden gedwongen en dit zou een plek van zwaar verkeer kunnen veroorzaken.
maak je echter geen zorgen! Die problemen zijn verdwenen met tokens, omdat het token zelf de gegevens voor die gebruiker bevat.
beveiliging
het token, geen cookie, wordt op elk verzoek verzonden en aangezien er geen cookie wordt verzonden, helpt dit CSRF-aanvallen te voorkomen. Zelfs als uw specifieke implementatie het token opslaat in een cookie aan de clientzijde, is de cookie slechts een opslagmechanisme in plaats van een authenticatie. Er is geen sessie-gebaseerde informatie te manipuleren omdat we geen sessie hebben!
het token verloopt ook na een bepaalde tijd, dus een gebruiker moet opnieuw inloggen. Dit helpt ons veilig te blijven. Er is ook het concept van token intrekking die ons in staat stelt om een specifiek token en zelfs een groep tokens ongeldig te maken op basis van dezelfde vergunningverlening.
uitbreidbaarheid (vriend van een vriend en machtigingen)
Tokens zullen ons toelaten om toepassingen te bouwen die machtigingen delen met een ander. We hebben bijvoorbeeld willekeurige sociale accounts gekoppeld aan onze belangrijkste accounts zoals Facebook of Twitter.
wanneer we inloggen op Twitter via een service (Laten we zeggen Buffer), staan we Buffer toe om te posten op onze Twitter-stream.
door tokens te gebruiken, bieden we op deze manier selectieve rechten aan toepassingen van derden. We kunnen zelfs onze eigen API bouwen en speciale toestemming tokens uitdelen als onze gebruikers toegang tot hun gegevens willen geven aan een andere toepassing.
meerdere Platforms en domeinen
we hadden het eerder al over CORS. Wanneer onze applicatie en service breidt, zullen we moeten worden het verstrekken van toegang tot allerlei apparaten en toepassingen (aangezien onze app zal zeker populair worden!).
omdat onze API alleen gegevens bevat, kunnen we ook de ontwerpkeuze maken om assets van een CDN te bedienen. Dit elimineert de problemen die CORS brengt nadat we een snelle header configuratie voor onze toepassing.
Access-Control-Allow-Origin: *onze gegevens en bronnen zijn nu beschikbaar voor aanvragen van elk domein zolang een gebruiker een geldig token heeft.
Standards-Based
bij het maken van het token, hebt u een paar opties. We zullen meer duiken in dit onderwerp wanneer we een API te beveiligen in een follow-up artikel, maar de standaard te gebruiken zou JSON Web Tokens.
deze handige debugger-en bibliotheekgrafiek toont de ondersteuning voor JSON-Webtokens. U kunt zien dat het heeft een grote hoeveelheid steun in een verscheidenheid van talen. Dit betekent dat je eigenlijk zou kunnen schakelen uit uw authenticatie mechanisme als je ervoor kiest om dit te doen in de toekomst!
conclusie
dit was slechts een blik op het hoe en waarom van token-gebaseerde authenticatie. Zoals altijd het geval is in de wereld van de veiligheid, is er veel meer aan elk onderwerp en het varieert per use case. We doken zelfs in een aantal onderwerpen op schaalbaarheid die ook een eigen gesprek verdient.
dit was een snel overzicht op hoog niveau, dus voel je vrij om te wijzen op alles wat werd gemist of eventuele vragen die u heeft over de zaak.
in ons volgende artikel, zullen we kijken naar de anatomie van JSON Web Tokens.
opmerking: ACAO header info en CSRF verduidelijkingen toevoegen (Met dank aan Emily Stark voor de artikel info)