Skip to content

Latest commit

 

History

History
138 lines (95 loc) · 4.59 KB

06.2.auth2.md

File metadata and controls

138 lines (95 loc) · 4.59 KB

Fyrirlestur 6.2 — Auðkenning 2

Vefforritun 2 — HBV403G

Ólafur Sverrir Kjartansson, osk@hi.is

Búa til notanda

  • Höfum núna kynnst því hvernig við getum auðkennt notanda sem við eigum til
  • En hvað með að búa til okkar eigin?
  • Ekki mikil viðbót...

Notendaumsjón

  • Þurfum að geyma notendur á hentugum stað
    • Við munum nota postgres
  • Bætum við route sem leyfir notanda að skrá sig, tekur a.m.k. við notendaauðkenni og lykilorði (username og password)
    • Getum hæglega skráð auka upplýsingar um notanda í leiðinni

Aðeins um notendanöfn

  • Að ákveða hvað séu lögleg notendanöfn er ekki jafn einfalt og maður myndi ætla
  • Notendanöfn innihalda stafi og það er til mikið af stöfum
    • "💩", "Оｌｉ", "點看" lögleg?
  • Alvöru vandamál með t.d. phishing

Replace a semicolon (;) with a greek question mark (;) in your friend's JavaScript and watch them pull their hair out over the syntax error

—Ben Johnson (@benbjohnson), November 16, 2014

Gleymt lykilorð

  • Seinasta púslið í því að setja saman alvöru notendaumsjónarkerfi er staðfesting á notanda
    • Yfirleitt gert með tölvupóst
  • Getum þá útfært gleymt lykilorð virkni
  • Förum ekki yfir

Vefþjónustur og auðkenning

  • Þegar við bætum auðkenningu við vefþjónusturnar okkar er það mjög sjaldan gert með sessions
  • Session skalast illa
    • Þurfum að geyma upplýsingar einhversstaðar á vefþjón
    • Ef við notum fleiri en einn vefþjón þarf að deila þessum upplýsingum
    • Þurfum að fletta upp upplýsingum í gagnageymslu til að fá lýsigögn, t.d. hvenær session var búið til
    • Öryggishættur tengdar cookies og session

Tokens

  • Með því að nota tokens sem eru undirritaðir af vefþjón losnum við mörg af þessum vandamálum
  • Getum stýrt því hvaða upplýsingar eru geymdar
  • Auðvelt að senda á milli, t.d. fyrir single sign-on kerfi
  • Gögn sem við viljum geyma eru sett saman með lýsigögnum og stillingum fyrir token
    • T.d. hvenær token rennur út
  • Vefþjónn undirritar með dulkóðunaraðferð og földum lykli
  • Client fær token og geymir, sendir með hverri request þar sem auðkenningar er krafist
    • Yfirleitt í Authorization HTTP hausnum

JWT

Noktun

  • Notum til að vita að sá sem heldur á token hafi á einhverjum tímapunkti auðkennt sig gagnvart okkur
  • Geymum engar viðkvæmar upplýsingar í token
  • Stillum token á að renna út á einhverjum tímapunkti og látum notanda þar með aukenna sig aftur

JWT, express og passport

  • Sækjum passport-jwt til þess að auðkenna með JWT gegnum passport
  • Til að undirrita token notum við jsonwebtoken
  • Svipað því að nota passport-local
    • Þurfum ekki að serialize'a notanda og viljum ekki nota session
const {
  Strategy,
  ExtractJwt
} = require('passport-jwt');

const jwtOptions = {
  jwtFromRequest: ExtractJwt
                    .fromAuthHeaderAsBearerToken(),
  secretOrKey: superSecret,
}
function strat(data, next) { ... }
passport.use(new Strategy(jwtOptions, strat));

Login endapunktur

  • Útbúum endapunkt sem client notar til að auðkenna sig og fá token
    • t.d. /login
  • Þar finnum við notanda og staðfestum lykilorð
  • Þar til token rennur út verður það jafngilt því að hafa notendanafn og lykilorð notanda
    • Þarf að passa upp!

Auðkenning

  • Client mun senda token með hverju request
  • Þurfum því alltaf að staðfesta token í hvert skipti sem notandi biður um eitthvað sem krefst auðkenningar
    • Er token í lagi? Stenst undirritun?
    • Er token útrunninn?
    • Fleiri athuganir sem við gætum viljað gera