Has anyone felt a need for consumer deauthentication? We've got the Service Provider deauthn taken care of, but there doesn't seem to be a way to force revokation of an AT from the outside.
This sort of thing is prone to phishing. Any consumer the user doesn't trust to hold their access tokens might spoof the deauthn, giving the false impression of a real logoff. I can't think of a way that doesn't involve the user actually seeing a "You logged off" message on the actual SP.
When a user tells an SP that they no longer want their account tied to the service, the SP is expected to throw away their tokens Meanwhile, the access provider continues to show that said SP remains authorized, forcing the user to de-authorize it again in order to keep things ordered.
I've been bouncing around the idea of an /oauth/deauthorize page that operates either like the "authorize this application" page or a signed call that expires the tokens on the provider's end.
Thoughts?
seth
On Mon, Apr 14, 2008 at 8:09 AM, Joseph Holsten <jos...@josephholsten.com> wrote:
> Has anyone felt a need for consumer deauthentication? We've got the > Service Provider deauthn taken care of, but there doesn't seem to be a > way to force revokation of an AT from the outside.
> This sort of thing is prone to phishing. Any consumer the user doesn't > trust to hold their access tokens might spoof the deauthn, giving the > false impression of a real logoff. I can't think of a way that doesn't > involve the user actually seeing a "You logged off" message on the > actual SP.
> Am I missing something? Anyone seen this pattern?
On Fri, Apr 18, 2008 at 6:54 PM, Seth Fitzsimmons <s...@mojodna.net> wrote: > Yes.
> When a user tells an SP that they no longer want their account tied to the > service, the SP is expected to throw away their tokens Meanwhile, the > access provider continues to show that said SP remains authorized, forcing > the user to de-authorize it again in order to keep things ordered.
> I've been bouncing around the idea of an /oauth/deauthorize page that > operates either like the "authorize this application" page or a signed call > that expires the tokens on the provider's end.
> Thoughts?
> seth
> On Mon, Apr 14, 2008 at 8:09 AM, Joseph Holsten <jos...@josephholsten.com> > wrote:
> > Has anyone felt a need for consumer deauthentication? We've got the > > Service Provider deauthn taken care of, but there doesn't seem to be a > > way to force revokation of an AT from the outside.
> > This sort of thing is prone to phishing. Any consumer the user doesn't > > trust to hold their access tokens might spoof the deauthn, giving the > > false impression of a real logoff. I can't think of a way that doesn't > > involve the user actually seeing a "You logged off" message on the > > actual SP.
> > Am I missing something? Anyone seen this pattern?
On Fri, Apr 18, 2008 at 10:26 PM, Brian Eaton <bea...@google.com> wrote:
> (Reading this mailing list always leaves me confused at first, and > sometimes better informed later.)
> What is the use case here? Who visits the deauthentication page, and > why? What does it do when they visit?
> On Fri, Apr 18, 2008 at 6:54 PM, Seth Fitzsimmons <s...@mojodna.net> wrote: > > Yes.
> > When a user tells an SP that they no longer want their account tied to the > > service, the SP is expected to throw away their tokens Meanwhile, the > > access provider continues to show that said SP remains authorized, forcing > > the user to de-authorize it again in order to keep things ordered.
> > I've been bouncing around the idea of an /oauth/deauthorize page that > > operates either like the "authorize this application" page or a signed call > > that expires the tokens on the provider's end.
> > Thoughts?
> > seth
> > On Mon, Apr 14, 2008 at 8:09 AM, Joseph Holsten <jos...@josephholsten.com> > > wrote:
> > > Has anyone felt a need for consumer deauthentication? We've got the > > > Service Provider deauthn taken care of, but there doesn't seem to be a > > > way to force revokation of an AT from the outside.
> > > This sort of thing is prone to phishing. Any consumer the user doesn't > > > trust to hold their access tokens might spoof the deauthn, giving the > > > false impression of a real logoff. I can't think of a way that doesn't > > > involve the user actually seeing a "You logged off" message on the > > > actual SP.
> > > Am I missing something? Anyone seen this pattern?
On Sat, Apr 19, 2008 at 10:14 AM, Adam Rosien <adam.ros...@gmail.com> wrote: > I believe they are proposing a HTML page where the User can revoke > Access Tokens of Consumers.
Service providers should definitely do that, but does it involve an OAuth extension? This seems like a matter that's between the user and the service provider, no need for the service provider and consumer to agree on a protocol.
> When a user tells an SP that they no longer want their account tied to the
> service, the SP is expected to throw away their tokens Meanwhile, the
> access provider continues to show that said SP remains authorized, forcing
> the user to de-authorize it again in order to keep things ordered.
What you describe is the consumer (or container) holding a defunct
access token because the service provider has removed it. Now, I would
expect when the consumer makes the next service provider data call,
for the defunct token to be passed and a 401 returned. As such, the
user shouldn't need to de-authorise because the consumer/container
will treat this as a the start of the oauth dialogue. It sorts itself
out?
> I've been bouncing around the idea of an /oauth/deauthorize page that
> operates either like the "authorize this application" page or a signed call
> that expires the tokens on the provider's end.
Each service provider is going to implement a page to de-authorise
consumers from profiles. What would be nice is if the consumer/
container provides a "check authorisation status" link. If the
consumer uses a single service provider, the link takes the user
straight to the SP authorisation url (so the customer can easily check
access rights and de-authorise if necessary). If more than one service
provider, a page lists all service providers with hyperlinks to the
authorisation url. I'm assuming the authorisation url can figure out
the user has already been authorised and offer revocation service
rather than offering /oauth/deauthorize as a separate url.
I suppose it is a hassle for users if a consumer has a more than one
service provider and needs to revoke them all in turn. This might be a
rare case and I don't feel strongly about it.
I don't share the concern about man in middle, because if a consumer
has an AT, it's likely they have it for valid reasons (given the
security wrap containers and service providers provide). So if oauth
supports a revoke token service, where the current AT was passed, this
might be okay. This would allow consumers to cleanup on behalf of the
user - when instructed to do so.
