[OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes
Pedro Felix <pmhsfelix@gmail.com> Wed, 10 October 2012 14:25 UTC
Return-Path: <pmhsfelix@gmail.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 593EF21F8782 for <oauth@ietfa.amsl.com>; Wed, 10 Oct 2012 07:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDGQExP3ram0 for <oauth@ietfa.amsl.com>; Wed, 10 Oct 2012 07:25:47 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 902C021F8758 for <oauth@ietf.org>; Wed, 10 Oct 2012 07:25:47 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so492444lam.31 for <oauth@ietf.org>; Wed, 10 Oct 2012 07:25:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OhZqggRrje2s7TkK282OQIhXMu86jIMPcStxSnS5WD0=; b=aaGCX0lTqtrUXh5EnzC71PZjQ+HMW3fqokGWQsFMKzZfUxxxF0ofG0wrk97Ys1cdiY sGWM4UAgfo56jpnTkZ8bMBkrLJNWzkO/VbnAr8pia/iCQZCznRNDU0RvDtm7fQF88NHM eYUCYrDPjIctoF5398nuvSbY7MrFX0Pw9CbKn8ajpyaNn1iK+VTdHMa7pjZ+Y8ueE4eu VIvy4yxg1vvAzNo7FlEvBIf0jGUDZRXE10GzOSSvN++tPRsUTGEKGHNmW2uZI34Rd0fM nU4oCNlaFYPvmwJNOO87QAspl900yf+IPOrcHSmuBl/wMNcLR35KKvimHjs+fMmKiusu hZAg==
MIME-Version: 1.0
Received: by 10.112.102.198 with SMTP id fq6mr9396734lbb.135.1349879146489; Wed, 10 Oct 2012 07:25:46 -0700 (PDT)
Received: by 10.112.61.5 with HTTP; Wed, 10 Oct 2012 07:25:46 -0700 (PDT)
Date: Wed, 10 Oct 2012 15:25:46 +0100
Message-ID: <CAD+AFDvoCGkohSZV02tgi0dEVn42XJvcDHY_owvbcZz907WOLg@mail.gmail.com>
From: Pedro Felix <pmhsfelix@gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="f46d0401fa290429ce04cbb53b5d"
Subject: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes
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: Wed, 10 Oct 2012 14:25:48 -0000
1) Out-of-band code transmission Currently Google OAuth2 implementation uses the special "urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. a) What is the reason for the absence in the spec? b) Is there any security problem associated with this usage? 2) Alternative "redirect_uri" schemes I'm also considering the use of alternative schemes on the "redirect_uri". For instance, a client app could use the "mailto:" scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however a) Weren't these scenarios considered by the working group? b) Is there a major security flaw on this usage? Thanks Pedro
- [OAUTH-WG] Out-of-band code delivery and alternat… Pedro Felix
- Re: [OAUTH-WG] Out-of-band code delivery and alte… Torsten Lodderstedt
- Re: [OAUTH-WG] Out-of-band code delivery and alte… Pedro Felix
- Re: [OAUTH-WG] Out-of-band code delivery and alte… Torsten Lodderstedt