Jag = Erik Davidsson

Teknologival¶

Backend¶

Backenden är ganska standard.

Providers¶

LU är ett krav för att det är väldigt smidigt för teknologer. Händelsevis så upptäcktes det att login med LU inte är en sak, utan att man istället ansluts till SWAMID, som är en organisation av identity providers för akademiska Sverige. Så inlogg från alla universitet är plug & play sålänge vi frågar:) (kanske t.o.m. utan att vi frågar)

Det diskuterades ifall mail var nödvändigt eller inte. Jag såg det som det smidigaste. Inlogg finns med mail utan lösenord, alltså får man en "logga in" länk på mail varje gång man försöker logga in. Detta har bättre säkerhet än mail + lösenord, då man alltid kan återställa lösenordet, vilket är motsvarigt vårt inloggningssätt. Mailinlogg används av admins.

För att få en länk till providerns hemsida så användaren kan logga in måste hemsidans frontend POST:a till en provider endpoint på auth backenden. Detta medför att vi säkert (inom gränserna att användaren använder en webbläsare) vet vilken hemsida användaren försöker logga in på (origin headern).

Iframe¶

Alla providers stödjer tekniskt både iframes och redirects. Iframes behövs för appen. Vissa SAML2 providers kan blocka att köras i en iframe:( Med redirects forslas användaren tillbaka till url:en definierad i continue_url i initiala provider-anropet, med en query parameter validated satt till true/false beroende på om authen lyckades. I en iframe får main-hemsidan ett message event från barn-iframen om hur det gick. Båda dessa funktioner implementeras i auth-frontend-libraryt.

Confirm datasharing¶

När auth tjänsten används av annat än https://teknologappen.se så visas en sida som frågar användaren om denna vill dela sina personuppgifter med tredjepartshemsidan (typ sektionssidor). Detta då vi inte har implicit samtycke för för mer än teknologappen, där vi juridiskt behöver namn & mail för att kunna skriva ut kvitton.

Allowed domains¶

I api.rs listas ett antal godkända domäner. Enligt muntligt avtal med LU så får inloggningstjänsten bara användas för interna syften som nyttar medlemmarna för sektionerna under TLTH. Därför bör bara sektionshemsidor listas där. Om man försöker använda tjänsten med en domän som inte är listad där blir man alltid rejected i sista steget (confirm-datasharing-steget) oberoende av vad användaren trycker.

Överföring av användaruppgifter till hemsidans backend¶

När en användare loggar in skickas dess uppgifter till en vald callback-url på hemsidans backend. Då kan hemsidans backend skapa ett användarobjekt i dess databas.

origin headern måste matcha callback-urlens domän, p.g.a. obvious säkerhetsskäl.

Verifiering¶

Jag tittade en del på OAuth (som inte är en inloggningstjänst egentligen) och OpenID (som bygger på OAuth och gör det till något som borde användas som login). Där fanns en del osmidigheter med protokollen som jag inte gillade men främst var problemet att där inte finns en OpenID server för Rust. Så då tänkte jag fuck it: vi handrollar vårt eget auth protokoll.

Auth-backenden utfärdar JWTs mot refresh tokens. Det skapas en ny refresh token vid varje JWT refresh. På så sätt kan vi meddela en användare om deras refresh token använts av någon annan (de har blivit hackade). Refresh tokens lagras som cross-domain Http-Only cookies. Detta gör de omöjliga att hämta från JS, alltså har XSS ingen påverkan (man kan ju dock få tillgång till JWTs:en). Refresh tokens är scoped till en domän.

Hemsidans backend kan lätt verifiera JWTen genom att hämta den publika nyckeln från https://auth.teknologappen.se/api/v0/verifying-key.

Detta valdes för prestanda. Hemsidans backend behöver aldrig prata med auth's backend förutom att få publika nyckeln.

JWTs är perfekta för detta syftet och en bred standard så det är rimligt för icke-rust-backends att verifiera JWTen (t.ex. på sektionssidor).