Re: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 09 January 2012 16:36 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA71E11E808A for <oauth@ietfa.amsl.com>; Mon, 9 Jan 2012 08:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+A3CSZPkM5e for <oauth@ietfa.amsl.com>; Mon, 9 Jan 2012 08:36:20 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1F111E8094 for <oauth@ietf.org>; Mon, 9 Jan 2012 08:36:20 -0800 (PST)
Received: from [80.187.107.161] (helo=[10.157.17.71]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1RkICn-0000pm-Dh; Mon, 09 Jan 2012 17:36:18 +0100
References: <048EBD85-F1B7-436F-953F-3E22DEC44DE3@uninett.no> <AEDA1B65E9329448939CEFA895C129E203F72449@studentserver.studentennet.local>
User-Agent: K-9 Mail for Android
In-Reply-To: <AEDA1B65E9329448939CEFA895C129E203F72449@studentserver.studentennet.local>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----GY4GB910UE8IFXL9KNDJ68ABT1T4QO"
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Mon, 09 Jan 2012 17:35:55 +0100
To: Bart Wiegmans <bart@all4students.nl>, Andreas Åkre Solberg <andreas.solberg@uninett.no>, oauth@ietf.org
Message-ID: <986f3503-15f9-4c1e-a974-e571060fe367@email.android.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Subject: Re: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jan 2012 16:36:24 -0000

Hi,

an invalid token should cause the server to reply with status code 401.

regards,
Torsten.



Bart Wiegmans <bart@all4students.nl> schrieb:

Hi,

As far as I know, the implementation of API endpoints is outside of the specification of OAuth. 
But the specification of Bearer Tokens state that the endpoint must return the HTTP 403 (Access Denied) status code, along with a WWW-Authenticate: Bearer response header. That should be enough to determine token invalidity. 

With kind regards,
Bart Wiegmans


-----Oorspronkelijk bericht-----
Van: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] Namens Andreas Åkre Solberg
Verzonden: maandag 9 januari 2012 9:41
Aan: oauth@ietf.org
Onderwerp: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries

Hi,

I'm trying to do an OAuth 2.0 library, and got a question:

I cannot find a standardized way for an OAuth protected endpoint to report to the client that the Token is not valid (expired or revoked). As a library developer, I'd like to take away as much of possible of the OAuth logic from the application. I need a way to distinguish applicaiton specific protocol errors, from OAuth related errors on protected endpoints.

If the library could detect this, it could also in example do refresh the token automatically, and even start a new flow if neccessary.

I'm sorry if the answer is obvious. 

Another question on token validity; the optional expires_in parameter. If I would like to indicate permanent validity, how can I express that? I assume that if I leave the parameter out it is not possible to distinguish between 'undefined / not specified' and 'infitite'. Putting the semanthics into a specific scope could off course work, but lack the feature of beeing standardized between providers.

Andreas
_____________________________________________

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth