summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <lwirzenius@wikimedia.org>2020-12-07 16:27:59 +0200
committerLars Wirzenius <lwirzenius@wikimedia.org>2020-12-07 16:27:59 +0200
commit63ccc44ca3556a8770e2818b264c93c5c9e4f791 (patch)
treec7829aa1e637464d88a2c175c78832d1f5cb61d7
parent9d619641b3f07b4bd073209acb2650240a536c0b (diff)
downloadwmf-talks-63ccc44ca3556a8770e2818b264c93c5c9e4f791.tar.gz
oauth talk: finish slides
-rw-r--r--2020-12-07-oauth2.md105
1 files changed, 78 insertions, 27 deletions
diff --git a/2020-12-07-oauth2.md b/2020-12-07-oauth2.md
index c684da1..5b15b16 100644
--- a/2020-12-07-oauth2.md
+++ b/2020-12-07-oauth2.md
@@ -1,14 +1,22 @@
+![](Anca.jpg)
+
+Kurt Bauschardt:
+[Anca the Weasel](https://commons.wikimedia.org/wiki/File:Anca_the_Weasel_(26984433186).jpg)
+
+
+-----------------------------------------------------------------------------
+
# Introduction
* OAuth 2.0: Something I implemented in a previous job.
* A common, almost fundamental protocol on the web, especially
- for APIs.
+ for APIs and (third-party) applications.
- - See: OKAPI
+ - See: OKAPI, Google, Microsoft, ...
-* Solves a common problem: letting one site act on behalf of an end
- user on another site.
+* Solves a common problem: letting one system act on behalf of an end
+ user on another system.
-----------------------------------------------------------------------------
@@ -36,7 +44,7 @@
# What OAuth2 is for?
-* Client authorization by end-user.
+* Client authorization (by end-user or otherwise).
* NOT end-user identification.
@@ -48,6 +56,7 @@
* NOT client authentication.
+
-----------------------------------------------------------------------------
I hereby authorize this specific third party to access these bits of
@@ -72,27 +81,41 @@ my authorization at any time.
-----------------------------------------------------------------------------
+~~~dot
+digraph "OAuth" {
+ Alice [shape="star"];
+ AMail [shape="cylinder"];
+ MailBooks [shape="ellipse"];
+
+ Alice -> MailBooks [label="one book, please"];
+ MailBooks -> AMail [label="Alice's emails, please"];
+ AMail -> Alice [label="May MB get your emails?"];
+}
+~~~
+
+-----------------------------------------------------------------------------
+
# Not this way
Alice gives MailBooks her username and password at AMail.
-MailBooks solemnly promises to not delete anything and to not send any
+MailBooks **solemnly promises** to not delete anything and to not send any
mail, and to forget the password after they've got what they need for
producing the book.
-Yeah right.
+_This works really, really well. Hunky-dory.
-----------------------------------------------------------------------------
# Not this way either
-MailBooks and AMail have a special agreement.
+MailBooks and AMail have a **special agreement**.
-AMail will give all the emails MailBooks asks for. MailBooks promises
+AMail will give all the emails MailBooks asks for. MailBooks **promises**
to only ask for email of people who say they want a book. MailBooks
asks its customers to not lie about who they are.
-There is no way in which this might go badly.
+_There is no way in which this might ever go badly in any way._
-----------------------------------------------------------------------------
@@ -100,13 +123,15 @@ There is no way in which this might go badly.
Alice forwards each email to MailBooks. All 1.3 million of them.
+_It will take not time at all. Easy peasy._
+
-----------------------------------------------------------------------------
# OAuth2: Overview
* Alice asks MailBooks for a book.
-* MailBooks tells her to authorize them on AMail.
+* MailBooks tells her to **authorize** them to AMail.
* Alice logs into AMail and clicks a button to authorize MailBooks.
AMail creates an **access token**.
@@ -125,15 +150,20 @@ Alice forwards each email to MailBooks. All 1.3 million of them.
~~~plantuml
@startuml
actor Alice
-entity "Book service" as Booksite
-database "Email service" as Email
+entity "MailBooks" as Booksite
+database "AMail" as Email
+
+hide footbox
Alice -> Booksite: Want book!
-Booksite -> Email: May I get emails?
-Email -> Alice: OK to give emails to Booksite?
+Booksite -> Alice: redirect to authorization
+Alice -> Email: follow redirection
+Email -> Alice: OK to give emails to MailBooks?
Alice -> Email: Sure!
-Email -> Booksite: Have an access token
-Booksite -> Email: Emails please
+Email -> Alice: redirect back to MailBooks, with access token
+Alice -> Booksite: follow redirection
+Booksite -> Email: Emails please, here is access token
+Email -> Booksite: the emails you requested
Booksite -> Alice: Your book, bitte
@enduml
~~~
@@ -143,29 +173,44 @@ Booksite -> Alice: Your book, bitte
# Details
-* HTTPS: always when credentials or tokens are transmitted
+* **HTTPS**: always when credentials or tokens are transmitted
+
+ - just use HTTPS always for everything
+ - a lot of HTTP redirects: can affect performance, be confusing
+
* access and **refresh tokens**: may be opaque to clients
- - but JWT is common
+
+ - but JWT is common, because OpenID Connect
+
* tokens are for a specific client and service
+
* tokens specify a **scope**: what operations they allow
+
* tokens expire &rarr; refresh tokens
+
+* tokens can be revoked &rarr; refresh tokens or start over
+
* endpoint discovery: originally unspecified
-----------------------------------------------------------------------------
-# Transaction 1: four specified grant variants
+# Transaction 1: get an access token (maybe refresh token)
+
+* four specified "flows" for this
+
+ - custom flows possible
-* authorization code: OKish, but security can be improved
+* _authorization code grant_: **OKish**
- * a lot of HTTP redirects
+* _client credentials grant_: **bots without end users**
-* client credentials: bots without end users
+* _implicit grant_: **don't use**, trusts browser and device too much
-* implicit: don't use, trusts browser too much
+ * new flow **PKCE** replaces this, for mobile and SPA
-* resource owner password credentials: NO, JUST NO!
+* _resource owner password credentials grant_: **NO, JUST NO!**
-* any of these may of course fail
+ - motivation: legacy systems
-----------------------------------------------------------------------------
@@ -173,15 +218,21 @@ Booksite -> Alice: Your book, bitte
* send request + token to resource provider (server)
+* typically as an HTTP header
+
+ - `Authorization: Bearer TOKEN`
+
-----------------------------------------------------------------------------
# Transaction 3: get new access token
-* When access token expires.
+* When access token expires or is revoked.
* Or when a client wants to give another client an access token,
possibly with less scope.
+
+ - might be a different part of the same client
-----------------------------------------------------------------------------