Jeg prøver å få greie på noen begreper og mekanismer og finne ut hvordan de forholder seg til hverandre eller hvordan de overlapper hverandre. Fokuset er på autentisering av en teoretisk webapplikasjon og mobilapplikasjon. **Fokuset er på den nøyaktige forskjellen mellom tokenbasert autentisering og informasjonskapselbasert autentisering og om/hvordan de overlapper hverandre.
http basic/digest og komplekse systemer som oauth/aws auth interesserer meg ikke.
Jeg har noen påstander som jeg gjerne vil legge frem og se om de stemmer.
Jeg håper jeg ikke bommer for mye og er takknemlig for all hjelp!
Ved øktbasert autentisering gjør serveren alt det tunge arbeidet på serversiden. Grovt sett autentiserer en klient seg med legitimasjon og mottar en session_id
(som kan lagres i en informasjonskapsel) og knytter denne til alle påfølgende utgående forespørsler. Så dette kan betraktes som et "token", ettersom det tilsvarer et sett med legitimasjon. Det er imidlertid ikke noe spesielt med denne session_id
-strengen. Det er bare en identifikator, og serveren gjør alt annet. Den er tilstandsbasert. Den knytter identifikatoren til en brukerkonto (f.eks. i minnet eller i en database). Den kan begrense denne økten til bestemte operasjoner eller en bestemt tidsperiode, og den kan ugyldiggjøre den hvis det er sikkerhetsproblemer. Og ikke minst kan den gjøre og endre alt dette underveis. I tillegg kan den logge alle brukerens bevegelser på nettstedet/nettstedene. Mulige ulemper er dårlig skalerbarhet (spesielt over flere serverparker) og høyt minneforbruk.
I Token-basert autentisering lagres ingen økt på serversiden (tilstandsløs). De innledende trinnene er de samme. Legitimasjon utveksles mot et token som deretter knyttes til alle påfølgende forespørsler (det kan også lagres i en informasjonskapsel). Men for å redusere minnebruken, gjøre det enkelt å skalere og øke fleksibiliteten (tokens kan utveksles med en annen klient) utstedes en streng med all nødvendig informasjon (tokenet) som sjekkes etter hver forespørsel fra klienten til serveren. Det finnes flere måter å bruke/opprette tokens på:
Ved hjelp av en hash-mekanisme, f.eks. HMAC-SHA1.
token = bruker_id|utløpsdato|HMAC(bruker_id|utløpsdato, k)
hvor user_id
og expiry_date
sendes i klartekst med den resulterende hashen vedlagt (k
er kun kjent for serveren).
Kryptering av tokenet symmetrisk, f.eks. med AES.
token = AES(user_id|expiry_date, x)
der x
representerer krypterings-/dekrypteringsnøkkelen.
Asymmetrisk kryptering, f.eks. med RSA
token = RSA(user_id|expiry_date, privat nøkkel)
**Produksjonssystemer er vanligvis mer komplekse enn disse to arketypene. Amazon bruker for eksempel begge mekanismene på nettstedet sitt. Hybrider kan også brukes til å utstede tokens som beskrevet i punkt 2 og også knytte en brukersesjon til den for sporing av brukeren eller eventuell tilbakekalling, samtidig som man beholder klientfleksibiliteten til klassiske tokens. OAuth 2.0 bruker også kortlivede og spesifikke bearer-tokens og mer langlivede refresh-tokens, f.eks. for å få bearer-tokens.
Kilder:
HTTP er tilstandsløst, og for å ha en autentisert tilstand trenger du en form for token som brukes til å referere til informasjon om brukeren. Denne økt-ID-en er vanligvis i form av et tilfeldig token som sendes som en informasjonskapselverdi. Et OAuth Access Token brukes til å identifisere en bruker og hvilke ressurser brukeren har tilgang til. I applikasjoner som bruker OAuth single-sign on, byttes vanligvis et OAuth Access token ut med en økt-ID som kan holde styr på en større mengde brukerstatus.
Fra en angripers perspektiv er det å kapre en økt-ID, eller OAuth Access Token, like bra som et brukernavn og passord, og noen ganger er det enda bedre. 2kt-ID-er må ha sikkerhetsegenskaper2 som beskytter brukerkontoer mot kompromittering.
Fra utviklerens perspektiv bør du aldri finne opp hjulet på nytt. Bruk øktadministratoren som leveres av plattformen din, og sørg for at den er konfigurert i henhold til OWASP Session Management guidelines.
Sesjonsbasert autentisering er nødvendig for å øke sikkerheten ved tilgang til ressurser: