[OAUTH-WG] Using OAuth for password reset

Jaap Francke <jaap.francke@iwelcome.com> Tue, 05 September 2017 15:14 UTC

Return-Path: <jaap.francke@iwelcome.com>
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 BB717132D52 for <oauth@ietfa.amsl.com>; Tue, 5 Sep 2017 08:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gNAuODELf90 for <oauth@ietfa.amsl.com>; Tue, 5 Sep 2017 08:14:01 -0700 (PDT)
Received: from SMTPGATE01.enterexchange.com (smtpgate01.enterexchange.com [109.205.192.241]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E7F124207 for <oauth@ietf.org>; Tue, 5 Sep 2017 08:14:00 -0700 (PDT)
From: Jaap Francke <jaap.francke@iwelcome.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Using OAuth for password reset
Thread-Index: AQHTJlmXd9rKfP1n0UmGaoCZoW8DPw==
Date: Tue, 05 Sep 2017 15:13:56 +0000
Message-ID: <CAFC5A2A-2AF8-4614-A245-415F1F62EDC7@iwelcome.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.17.5.138]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BF48EEDCF05E454FBC028FBE8B6FFF2C@enterexchange.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HiNw4v3rvPpVizGm_usKKSsKppY>
Subject: [OAUTH-WG] Using OAuth for password reset
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Sep 2017 15:14:03 -0000

Hi all,

I was wondering if anyone considered using OAuth for password resets. Or maybe this is common practice, I don’t know.

My line of thinking is that a password is "just-another-resource" that is stored at a resource server.
So the resource server requires an access token for anyone/any client that wants to update/change the password.
The authorisation server that issues access-tokens somehow needs to authenticate the client that wants an access token for changing a certain password.

Authentication is half in-scope and half out-of-scope of OAuth specifications.
In the Authorisation Code grant (AC), it is left out-of-scope how the AS authenticates the RO, but it does state it should happen through the user-agent during the execution of the grant.
In the ResourceOwner password credential (ROPC) grant, the username/password is sent to the AS as part of the authorisation request / redirect.

For a password reset scenario, I would say we need a new grant which would be inbetween AC-grant and ROPC-grant:
- it starts with a redirect to the AS including a “password reset token” - somewhat similar to the ROPC-grant: the password reset-token can be viewed as combination of username and a (one-time) password. This is basically clicking on a password reset link
- subsequently the AS could perform additional authentication steps (e.g. 2FA-SMS) - similar to what is possible with the AC-grant
- when AS thinks the user is sufficiently authenticated, the AS could issue the authorisation code and things would proceed as with the AC-grant

Obviously this is preceeded by a request for a password-reset link, which gets sent to the legitimate resource owner Out-Of-Bound via email, SMS, or whatsoever.

Am I making things too complicated here? Or would this be the proper way to do it? I’m trying to hook-up to the most secure OAuth mechanisms.
Any thoughts?

Jaap Francke