Re: [OAUTH-WG] token revocation from a different client

Thomas Broyer <> Wed, 31 May 2017 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E333128B37 for <>; Wed, 31 May 2017 05:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Umekq9sXUF4z for <>; Wed, 31 May 2017 05:57:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16AB81289B0 for <>; Wed, 31 May 2017 05:57:42 -0700 (PDT)
Received: by with SMTP id y4so8655135uay.2 for <>; Wed, 31 May 2017 05:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D/uek+cJJoAI+fTdbeuh3zt3NrJYOLUBMLm/MVFPZDA=; b=LJmXD13KqcjMlmk4rF9AmE/wKgnabY4cjN6ueRVbS5QdcC2eUswmJ7kjl3wv6NIuNU r515vXj/GkNbCT7JG6wn7HHswRW788dYAW4gBoAk+eCrVvKphcWB4Vn5Wd+RpoLkvaGg OkYUG/qJ9HEl3qiuVeUX8wkA4whx3w991fd4Y+GiW6cfQXmKr4fSHHpNFmgao4O/QGjj sHpKCDlNz5OaQl1ugw8IVcLo96GooT+tZvuPB3oL8RtVtO7lck1QKcwQbUEpO3J2AHe/ /+UMkG9MDjXwHhvOjkfrEgPjTQTqLbGHfVcMA6MG6XyunLmZZ1YbzPDH/tRifzitH2KH OZZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D/uek+cJJoAI+fTdbeuh3zt3NrJYOLUBMLm/MVFPZDA=; b=VXuW0P+w53YaL6aZqs/Z9hN9DYa5QsnUpolPGxg+/v5pDQy+40W1vQiUjeJqu2B2/Y e/dHJqVrNRlpCAD7pfttQFq1IrstdHLNR305drquVrS5bvtsFvcnflH1YcGUqSjRQLLq yI7x6sjPswst8mUqDS6djY/AtK6OYOiitVANO+ZLhaRxpPJr251DETZVJs/lAf1paPz5 GdqXNEx3JZ30SpMsddon6D6KS+w1jLK45eeIfrORphY055t6Q+y8mDBAZD5ob2qKaon4 l3BtmAjuJaltq5cNNbvEBval+ke0GRAwSiI1GMwcdUYity0uIhkqU/WXPYpZy5fgdwWT 6jqw==
X-Gm-Message-State: AODbwcAA1gm4l/8hdPgr+2gJTnEA39jnXclVltXL3WZgjYRWRuq7P1fC D3Z8DS28dPad6IQtv4wF9v20VWntQynd
X-Received: by with SMTP id e13mr13195278uah.66.1496235461252; Wed, 31 May 2017 05:57:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Thomas Broyer <>
Date: Wed, 31 May 2017 12:57:30 +0000
Message-ID: <>
To: Jaap Francke <>, "" <>
Content-Type: multipart/alternative; boundary="f403043ee9b02b20880550d177d4"
Archived-At: <>
Subject: Re: [OAUTH-WG] token revocation from a different client
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 May 2017 12:57:44 -0000

On Wed, May 31, 2017 at 12:01 PM Jaap Francke <>

> Hi all,
> It’s only since recently that I’m sticking my nose deeper into the various
> OAUTH (draft) specifications.
> I also recently joined this mailing list.
> I have a question and I hope someone can help me.
> I’ve been looking for a mechanism/endpoint/specification for token
> revocation.
> RFC7009 is aimed at token revocation by the client itself - logoff is the
> typical use case.
> What I’m looking for is a possibility for the enduser (resource owner) to
> revoke one of his tokens from a different client.
> Use cases for this would be:
> - suspection that password is compromised, so enduser wants to change his
> password and terminate all sessions on any device. For such devices to
> regain access, they would need the new password.
> - stolen/lost device; the enduser should be able to revoke specific
> access/refresh-tokesn that have been issued for the stolen/lost device.
> Any thoughts on this?

That's outside the scope of OAuth I'm afraid.

If the AS is the same as the one where the user does those actions, and
then it's entirely internal (RFC6749/6750 define how clients are "notified"
of it – their token is rejected with invalid_token error code).
If the application allowing the user to do these actions is a special kind
of client to the AS, then there'll likely be APIs it can use to list
current tokens and authorization grants and allow to revoke them, or revoke
all of them at once. In any case, it'd be a special API that either would
require a specific scope (that you'd likely only grant to that client) or
would allow access based on the client only (either using client
credentials, or looking at the

There might exist specifications for such APIs already, but I'm not aware
of them (i.e. probably not from the OAuth WG)