From 23e26e1247b69fb0d7d6a60917e3ff0ebdc876a7 Mon Sep 17 00:00:00 2001 From: coolaj86 Date: Mon, 7 Aug 2017 21:07:59 +0000 Subject: [PATCH] Update 'README.md' --- README.md | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index bc8629c..d3133ac 100644 --- a/README.md +++ b/README.md @@ -247,12 +247,19 @@ The UI should be updated with the name and icon specified in the issuer directiv For an issuer such as smithfam.net the directives must specify that the `authorization_dialog` endpoint is `https://smithfam.net/#/authorization_dialog/` -### First Token Grant / First Login +**First Token Grant / First Login** Once the issuer has been discovered the azp must store any state about the subject or application and construct a url to place in an anchor tag that will either redirect the window to the issuer directly, or open a popup window by using the `_target` attribute. According to browser policy, `window.open` may not be used asynchronously (no promises or requests), if it is used. +**Pre-Authorized Token Grant / Subsequent Logins** + +The authorization dialog may be opened from a hidden iFrame. If the user is signed in and has already authorized the app a token will be granted. Otherwise an error will be issued. + + +### Step 1 + Example **authorization dialog** url (using the example above): ``` @@ -278,4 +285,20 @@ In OAuth3 `client_uri` replaces `client_id` and so `client_id` is only necessary TODO It should also be possible to pass qualifiers for the security requirements of the azp (recency of login, mfa requirements, etc). -### Pre-Authorized Token Grant / Subsequent Logins \ No newline at end of file +### Step 2 (determine subject / get username/email) + +The user will be asked for their email or cloud address. + +It is up to the issuer's implementation to decide, but it is possible that the issuer will delegate to the issuer specified by the address. + +If `subject` was provided (or the user is logged in), this step will be skipped. + +### Step 3 (authenticate / login) + +How authentication is to be done is an implementation detail of the issuer. + +It is recommended to avoid using passwords and to instead use device-based authentication. + +In the reference implementation the user is sent an email with a login code or the device generates a new public/private keypair. + +### step 4 (authorize / grant) \ No newline at end of file