All important points. I'm not sure it affects whether refresh_tokens
should be bound to the authenticated session or not. If using a
continuous authentication model, it just means that as long as the AS/OP
believes the authentication session is valid, the refresh_token will
also continue to be valid. When the authentication session is determined
to be invalid, then the refresh_token is also revoked. In this
"continuous authentication" model, it feels like forcing the user to
re-authenticate would be a last resort. Instead other mechanisms would
be used to increase the confidence that the identified user is correct.
On 11/20/18 5:47 PM, David Waite wrote:
On Nov 20, 2018, at 1:37 PM, Aaron Parecki <aa...@parecki.com
<mailto:aa...@parecki.com>> wrote:
The new section on refresh tokens is great! I have a couple
questions/comments about some of the details.
Authorization servers may revoke refresh tokens automatically in case
of a security event, such as:
o logout at the authorization server
This doesn't sound like the desired behavior for mobile apps, where
the user's expectation of how long they are logged in to the mobile
app is not tied to their web session where they authorized the app.
However this does likely match a user's expectation when authorizing
a browser-based app. Should this be clarified that it should not
apply to the mobile app case, or only apply to browser-based apps?
There is also the model where web sessions are perpetual; where you
are evaluating access against a confidence that it is the legitimate
user against known threats. In that model, you require authentication
(perhaps by invalidating a client’s access and refresh tokens) as
needed to rebuild that confidence.
This still is considered an online model; the offline model would be
distinguished by evaluating the confidence that a client is still
trusted and acting in the user’s interests.
In terms of user-initiated logout - logout is an interesting action,
with both broad and miscommunicated purpose. I’ve found three
different verbalizations of why a user hits this button:
1. It must be here for some reason, so I think I’m supposed to hit it
when I’m done (aka 'security hygiene')
2. I suspect I might not be the next person who interacts with this
device, so you should ask me who I am before allowing future access
(aka ‘is this still you’)
3. I want software on this device to stop being able to access my
accounts, and to destroy any cached information (aka ‘kill switch’)
All could be expected to stop access by online clients, while someone
operating under expectation #3 could extend even to stopping offline
access.
Likewise, it could be said that users with expectation #2 would resume
access with previous scopes after an authentication, while expectation
#3 would imply a need to reestablish consent to resume.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
