coolaj86/OAUTH3-SPEC
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update 'README.md'

Browse Source
This commit is contained in:
AJ ONeal 2017-08-07 21:07:59 +00:00
parent aae1320d7b
commit 23e26e1247
1 changed files with 25 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
README.md
View File

@ -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
### 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)