Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob

John Bradley <ve7jtb@ve7jtb.com> Tue, 10 October 2017 15:04 UTC

Return-Path: <ve7jtb@ve7jtb.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 B6B1113334E for <oauth@ietfa.amsl.com>; Tue, 10 Oct 2017 08:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
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 bftee78mAwfP for <oauth@ietfa.amsl.com>; Tue, 10 Oct 2017 08:03:57 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DC6134E27 for <oauth@ietf.org>; Tue, 10 Oct 2017 08:02:24 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id x54so52050283qth.12 for <oauth@ietf.org>; Tue, 10 Oct 2017 08:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7kim6GkZH6SEo+tihiE2JnYrrqKUFSe1Z5HHdB5LGTQ=; b=tV3E7RGPYlCUrhGgmde9cvezTo8JT7lS4jFZkY4Ls+EdkzzRRSD1qDOsAZfAO5ZYXN xES2H2DbbWntoHVgruuXZXVTsU0eDD+E3mNZiIvFV2r+ZaUfqHGHqeENkTBrcblbGep7 xUAZkMRf6k5EYDZ3oa4D+cTBZuVE1EKYWyHZsZJ4KE/r1xRpnx1WmQwag1IJmQDXXuqX PVlOO9Q1ECTvszLYe1b+NkIyVuy4Qssq/kDn00lA3zIcettOLSbYEqJ5pekyGkpESeTJ 5ZJYjs3EP0ru6xP460vur0hQLMqikCA+aA2z4d8afr5lY9f6bCLd5k1ZjAmaw5rCuX1t ve/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7kim6GkZH6SEo+tihiE2JnYrrqKUFSe1Z5HHdB5LGTQ=; b=EOUz5hCqhePxJgHTcOgxFKHsd4JDImf+4w9RMdyfw+RMebJcT/ZGIE0r0TOVCIeTpO 1iwVcssibsHXMm4cA4CR1A48iMog7a+u7eAqrvP4c5lKJaGhp8Nk45lFRt3Ew0FR2lhP F9mmxnfDAqEpMsnc0lhCBtJAcpbcFh/cCHVdI09tsyhmFUiQwo5z0kUL5ZXFtDqA7X7m eeO/LR8AWbirx7WKBlCjV7jvUAk+K8NqWftJCe2rxqlbAWChdOeyx6gwMaw8FmAyxNqX fFzxwNIoeMtJZcY4Xd54caKs1a0j93KJjtiYofXFani2tsTNor/QKxTEZqZqBsMYxzsp yuHg==
X-Gm-Message-State: AMCzsaWNrmVQ42zHZkfGNUqlK79U/uRWM2xqudng5XcgZVUeVqwHJiNr 4Dd+ZgCh3EeZWf98KN5tNZ1fnLqQPpQ=
X-Google-Smtp-Source: AOwi7QAPOG8Y5z1A4X4XGn4mfGrci0VB5bRggTpKCoxuviZcs+JXfJFnyPpsvqN2IXU+p4lNwwkuXw==
X-Received: by 10.200.23.153 with SMTP id o25mr20614656qtj.119.1507647743441; Tue, 10 Oct 2017 08:02:23 -0700 (PDT)
Received: from johns-mbp.lan ([191.115.185.170]) by smtp.gmail.com with ESMTPSA id f4sm6609779qtg.35.2017.10.10.08.02.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Oct 2017 08:02:22 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <5C19128A-51FF-4F3B-AC1A-E04E0ABEC3D5@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Tue, 10 Oct 2017 12:02:18 -0300
In-Reply-To: <CAB3ntOvgXC4jWhGm7qNLSX94v35ZE7E0zy3Q0YZWOh-S+PRpow@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
To: Jim Willeke <jim@willeke.com>
References: <CAB3ntOvgXC4jWhGm7qNLSX94v35ZE7E0zy3Q0YZWOh-S+PRpow@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.1.7)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="f403045d62ba3b65d5055b3298cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5CkOmL7sP2f_gHcbwknSY0MD60w>
Subject: Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob
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, 10 Oct 2017 15:04:08 -0000

 urn:ietf:wg:oauth:2.0:oob is a google thing that is not part of the OAuth 2 specification.

I think it was mostly a windows thing.

It is not a real redirect URI it is used as a flag to the authorization server to have the result returned “Out Of Band” and the user cut and paste the token.

On windows applications could snoop the title bars of other apps so programatically retrieve the token value from the title bar.

I don’t really want to put effort into expanding all the reasons this is not secure.

I don’t honestly know what would happen if you sent that redirect URI to a non Google AS probably nothing good.   
It is not part of the OAuth specification and not something people should use without having a good reason and understanding the security implications.

William and I documented several ways to impliment native applications on OSX and Windows in RFC8252.

On windows you are really best off using a UWP app and the native token broker with the code flow.

Documentation
https://developers.google.com/api-client-library/python/auth/installed-app

This value signals to the Google Authorization Server that the authorization code should be returned in the title bar of the browser, with the page text prompting the user to copy the code and paste it in the application. This is useful when the client (such as a Windows application) cannot listen on an HTTP port without significant client configuration.

When you use this value, your application can then detect that the page has loaded, and can read the title of the HTML page to obtain the authorization code. It is then up to your application to close the browser window if you want to ensure that the user never sees the page that contains the authorization code. The mechanism for doing this varies from platform to platform.

If your platform doesn't allow you to detect that the page has loaded or read the title of the page, you can have the user paste the code back to your application, as prompted by the text in the confirmation page that the OAuth 2.0 server generates.


John B.
> On Oct 10, 2017, at 8:22 AM, Jim Willeke <jim@willeke.com> wrote:
> 
> Wondering if you could help with Questions on urn:ietf:wg:oauth:2.0:oob as it appears to be an almost common usage, but no IETF documentation or registration that we can find on the defined usage.
> 
> This has come up on several occasions.
> https://stackoverflow.com/q/46643795/88122 <https://stackoverflow.com/q/46643795/88122>
> http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html <http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html>
> https://github.com/doorkeeper-gem/doorkeeper/issues/514 <https://github.com/doorkeeper-gem/doorkeeper/issues/514>
> https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html <https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html>
> 
> Should it be registered or defined? 
> (or am I missing something?)
> 
> With best regards,
> 
> --
> -jim
> Jim Willeke
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth