Difference between revisions of "Self-issued Reconnection"
From MgmtWiki
(→Context) |
|||
(8 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
** The maintenance of a signed-in session. | ** The maintenance of a signed-in session. | ||
** The reconnection of a user session when for a continuing relationship. | ** The reconnection of a user session when for a continuing relationship. | ||
+ | * Refresh Token | ||
+ | * There categories of [[Relying Party]] generated [[User Experience]] (UX): | ||
+ | ** Pure web UX = no user actions needed to enable the UX. | ||
+ | ** [[Progressive Web App]] = requires user acceptance of app. | ||
+ | ** [[Native App]] = requires user to download and accept app. | ||
==References== | ==References== | ||
− | * Currently supported by a | + | * Currently supported by a browser-based [[Password Manager]]. |
− | * See also the [[Vendor | + | * See also the [[Vendor Relationship Manager]] |
+ | |||
[[Category: Authentication]] | [[Category: Authentication]] |
Latest revision as of 16:59, 4 November 2021
Full Name or Meme
The experience for the user and the Relying Party over time requires a quick reconnection at the user's pleasure.
Context
- The two original reasons for browser Cookies are:
- The maintenance of a signed-in session.
- The reconnection of a user session when for a continuing relationship.
- Refresh Token
- There categories of Relying Party generated User Experience (UX):
- Pure web UX = no user actions needed to enable the UX.
- Progressive Web App = requires user acceptance of app.
- Native App = requires user to download and accept app.
References
- Currently supported by a browser-based Password Manager.
- See also the Vendor Relationship Manager