[OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication
Colin Snover <ietf.org@zetafleet.com> Fri, 25 June 2010 04:07 UTC
Return-Path: <ietf.org@zetafleet.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE8D3A67E2 for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 21:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxj3dlb-IBuC for <oauth@core3.amsl.com>; Thu, 24 Jun 2010 21:07:22 -0700 (PDT)
Received: from one.acitia.com (one.acitia.com [66.135.55.251]) by core3.amsl.com (Postfix) with ESMTP id C317C3A676A for <oauth@ietf.org>; Thu, 24 Jun 2010 21:07:22 -0700 (PDT)
Received: from c-75-73-43-136.hsd1.mn.comcast.net ([75.73.43.136] helo=Trillian.hsd1.mn.comcast.net) by one.acitia.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <ietf.org@zetafleet.com>) id 1OS0Oq-00019I-BS for oauth@ietf.org; Fri, 25 Jun 2010 04:20:20 +0000
Message-ID: <4C242B7C.7040002@zetafleet.com>
Date: Thu, 24 Jun 2010 23:07:24 -0500
From: Colin Snover <ietf.org@zetafleet.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: oauth@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [OAUTH-WG] Add an option to authorization endpoint to force end-user re-authentication
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 25 Jun 2010 04:08:40 -0000
Hi everyone, I apologise if this has been discussed previously; I searched the list and did not see anything about it. I have been working extensively with OAuth as a client author. A big limitation that we are consistently running into with the way OAuth currently works is that there is no way to tell the authorization server that it needs to ask which end-user is requesting access. In instances where an end-user may have more than one account on a single provider, or where multiple end-users share the same computer, a problem occurs when the provider assumes that the account currently logged-in in the user-agent is the one that the end-user wants to connect. This assumption, while useful in most cases, causes major problems and a very frustrating user experience when the client has previously been authorised for the logged-in account and the provider immediately redirects back with an access token. In these cases, the user has no ability to choose to authorize a different account unless they manually log out of the provider’s site first or revoke authorization from the provider’s site. We need a way for the client to tell the authorization server “please do not automatically assume that the account currently logged-in is the account that we are requesting access for”. I would propose adding a new optional query component to the end-user authorization endpoint, force_auth. When this query component exists and is equal to 1, a provider MUST ask for the user’s credentials before either automatically redirecting back (if the client is already authorized) or presenting them with the prompt for authorization. Thank you for your time and consideration of this matter. I hope this feature or something similar can make it into OAuth 2, since otherwise we are going to have huge headaches and may end up needing to resort to cross-site request forgery to force user-agents to log out of provider sites. If I have been unclear at all, please let me know and I will be happy to clarify. Regards, -- Colin Snover http://zetafleet.com
- [OAUTH-WG] Add an option to authorization endpoin… Colin Snover
- Re: [OAUTH-WG] Add an option to authorization end… Luke Shepard
- Re: [OAUTH-WG] Add an option to authorization end… Colin Snover
- Re: [OAUTH-WG] Add an option to authorization end… Colin Snover