[Se-leg-ref] Kommentarer på uppdaterad dokumentation

Verkar som mitt tidigare svar inte kommit till listan, försöker igen: (tl;dr: Johan har hittat det viktigaste stycket, se hans mail.) Hej Magnus, Jag ska försöka adressera dina funderingar angående spec-compliance: OpenID Connect fungerar i vanliga fall (för autentisering på webben, som är det vanligast use case’t i dagsläget) såhär: 1. Användaren surfar till rp.example.com och klickar på logga in 2. RP’n gör ett authentication request genom att redirect’a användaren i webbläsaren till op.example.com/authenticate 3. Användaren autentiserar sig på något sätt (out-of-band för OIDC spec’en) 4. OP’n skickar ett authentication request genom att redirect’a användaren i webbläsaren till rp.example.com/redirect_uri Det viktiga, men osynliga, faktum är att det finns en webbläsare (”user agent” i specarna) som sköter punkt-till-punkt kommunikationen. Så på HTTP request nivå händer egentligen följande (lite förenklat/förkortat): 1. GET rp.example.com, sen GET rp.example.com/login 2. RP’n svarar med 302 och en Location header som innehåller OP’s authentication request ‘authorization_endpoint’, “Location: op.example.com/authenticate?<auth req params>” a. Här kommer webbläsaren in och följer redirect’en, GET op.example.com/authenticate 3. Användaren autentiserar sig (kommer antagligen inkludera lite fler HTTP requests, men dessa är utanför spec’en) 4. OP’n svarar till slut med en redirect: 302 och en Location header som innehåller authentication response RP’s redirect_uri: “Location: rp.example.com/redirect_uri?<auth resp params>” a. Här kommer webbläsaren in och följer redirect’en, GET rp.example.com/redirect_uri Så även i det vanliga webb-flödet av OIDC, måste RP’n vara publikt åtkomlig för HTTP request till det man publicerar som redirect_uri för att 4a ska fungera. I grunden är OIDC ett asynkront protokoll på samma sätt SAML; man får *inte* tillbaka authentication response som ett HTTP response på authentication request’ets HTTP request. Saken med SE-Leg är att vi inte har någon webbläsare/user agent. Så vi låter helt enkelt OP’n och RP’n kommunicera direkt med varandra. Alltså har vi klippt bort både 2a (authentication request ska skickas som en POST till authorization_endpoint i SE-Leg) och 4a (OP gör GET direkt på redirect_uri i SE-Leg). Jag ser inget i specen som skulle förhindra detta use case. Ert förslag är ett litet avsteg från OIDC-flödet eftersom det antar att RP’n är den som initierar authentication response. Det är OP’n som gör det, genom att skicka svaret till RP’s redirect_uri. Först senare i flödet, för token_endpoint och userinfo_endpoint, sker det direkta HTTP request/response som RP’n initierar. Hoppas det blev lite klarare. Vänliga hälsningar, --- Rebecka Gulliksson ICT Services and System Development (ITS) Umeå University SE-901 87 Umeå, Sweden rebecka.gulliksson at umu.se www.its.umu.se On 30/09/16 10:51, "se-leg-ref on behalf of Johan Lundberg" < se-leg-ref-bounces at lists.sunet.se on behalf of lundberg at nordu.net> wrote: Ska börja med att jag också är ny på det här med OIDC men i https://too ls.ietf.org/html/rfc6749#section-4.1.2 står det ju att: "If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the redirection URI" Där authorization server är OP och client är RP. Jag kan inte heller se någon annan anledning till att att RPn (enligt spec) måste registrera en redirect_uri om den inte skulle användas för att initiera kommunikation från OPn. Sen tycker jag också att det är en feature att OPn hör av sig till RPn när resultatet av autentiseringen är klar. Det är betyder att OPn kan göra extra kontroller av den information användaren och ombudet har uppgivit (som tar okänt lång tid) innan resultatet skickas till RPn. Annars måste ju alla RPs polla OPn för uppdateringar för alla pågånde autentiseringar. _______________________________________________ se-leg-ref mailing list se-leg-ref at lists.sunet.se https://lists.sunet.se/listinfo/se-leg-ref