Ik dacht dat OAuth in feite een op tokens gebaseerde authenticatiespecificatie is, maar meestal gedragen frameworks zich alsof er een verschil tussen is. Bijvoorbeeld, zoals weergegeven in de onderstaande afbeelding, vraagt Jhipsterof een op OAuth gebaseerde of een op token gebaseerde authenticatie moet worden gebruikt.
Zijn dit niet hetzelfde? Wat is precies het verschil, aangezien beide tokens in hun implementaties bevatten?
Antwoord 1, autoriteit 100%
Dit is een goede vraag — er is veel verwarring rond tokens en OAuth.
Ten eerste, als je OAuth noemt, doel je waarschijnlijk op de OAuth2-standaard. Dit is de nieuwste versie van het OAuth-protocol en daar hebben de meeste mensen het specifiek over als ze ‘OAuth’ zeggen.
Het OAuth-protocol ondersteunt verschillende soorten authenticatie en autorisatie (4 om precies te zijn).
Ten tweede werkt het OAuth-protocol door gebruikers te authenticeren via tokens. Het idee hier is dit:
In plaats van dat uw gebruiker bij elk verzoek zijn werkelijke inloggegevens naar uw server stuurt (zoals bij Basic Auth, waarbij een gebruiker voor elk verzoek zijn gebruikersnaam/wachtwoord naar de server stuurt), wisselt u met OAuth eerst uw gebruiker uit inloggegevens voor een ‘token’ en authenticeer vervolgens gebruikers op basis van dit ‘token’.
Het idee van OAuth is dat door te eisen dat gebruikers hun vertrouwelijke gegevens minder vaak via het netwerk doorgeven, er minder slechte dingen kunnen gebeuren. (Dit is hoe dan ook het idee.)
Hier komen tokens om de hoek kijken: de OAuth-specificatie is gebaseerd op het concept van tokens, maar specificeert NIET WAT EEN TOKEN IS.
In de meest ‘algemene’ zin is een token slechts een tekenreeks die een gebruiker op unieke wijze identificeert. Dat is het.
Mensen realiseerden zich dit en ontwikkelden een nieuwe standaard voor het maken van tokens, de JSON Web Token-standaard. Deze standaard biedt in feite een reeks regels voor het maken van tokens op een zeer specifieke manier, waardoor tokens in het algemeen nuttiger voor u zijn.
JWT’s laten je dingen doen als:
- Cryptografisch een token ondertekenen zodat u weet dat er niet met een token is geknoeid door een gebruiker.
- Versleutel tokens zodat de inhoud niet in platte tekst kan worden gelezen.
- Sluit JSON-gegevens BINNENKANT van een tokenstring op een standaard manier in.
Voor het grootste deel: vrijwel iedereen in de ontwikkelingsgemeenschap is het erover eens dat als je een soort OAuth gebruikt, de tokens die je gebruikt JSON-webtokens moeten zijn.
==========
Oké! Nu we het achtergrondverhaal hebben behandeld, wil ik je vraag beantwoorden.
De keuze die u hierboven maakt, is of u de volledige OAuth2-specificatie voor authenticatie/autorisatie wilt inschakelen (wat vrij complex is), of dat u gewoon wat basis ‘token-authenticatie’ wilt.
Omdat het OAuth-protocol meerdere verschillende manieren biedt om te authenticeren op een manier die VOLDOET aan de STANDAARDEN, voegt het veel complexiteit toe aan de meeste authenticatiesystemen.
Hierdoor bieden veel frameworks een ‘gedimde’ versie van de OAuth2 Password Grant-stroom, wat in wezen een eenvoudige methode is waarbij:
- Een gebruiker stuurt zijn gebruikersnaam/wachtwoord naar uw server via een URL zoals /login.
- Uw server genereert een JWT-token voor de gebruiker.
- Uw server geeft dat token terug aan de gebruiker.
- De gebruiker slaat dit token op in zijn cookies, mobiele apparaat of eventuele API-server, waar hij het gebruikt om verzoeken in te dienen.
Nogmaals: de bovenstaande stroom is NIET OAuth-compatibel, maar is een iets eenvoudigere versie die NOG STEEDS tokens gebruikt.
Het belangrijkste punt hier is dat tokens (JWT’s) over het algemeen nuttig zijn en niet gekoppeld hoeven te worden aan de OAuth-stroom.
Ik realiseer me dat dit een muur van tekst is, maar hopelijk beantwoordt het je vraag uitgebreider =)
Antwoord 2, autoriteit 3%
Als u een bron aanvraagt bij een beveiligde webservice, kunt u een verificatietoken opgeven voor de aanroep. Het token fungeert als “geheime code” voor toegang tot de bron.
OAuth is slechts een specifiek type verificatiemethode op basis van tokens.
Antwoord 3, autoriteit 3%
OAuth is een specificatie voor autorisatie, niet voor authenticatie
OAuth 2.0 is een specificatie voor autorisatie, maar NIET voor authenticatie. RFC 6749, 3.1. Authorization Endpointzegt expliciet het volgende:
Het autorisatie-eindpunt wordt gebruikt om te communiceren met de resource-eigenaar
en het verkrijgen van een autorisatiebeurs. De autorisatieserver MOET eerst
de identiteit van de resource-eigenaar verifiëren. De manier waarop de
autorisatieserver verifieert de resource-eigenaar (bijv. gebruikersnaam
en wachtwoord login, sessiecookies) valt buiten het bestek hiervan
specificatie.
Gebruik OAuth alleen als u toegang wilt geven tot een service van een derde partij voor uw apis. Zelfs als u OAuth gebruikt, heeft u een soort authenticatie nodig (op token gebaseerd of sessiegebaseerd, enz.) om het gebruik te authenticeren. OAuth is niet ontworpen voor authenticatie.
bekijk deze vraag.