Re: [OAUTH-WG] End User Authentication using OAuth 2.0

Sergey Beryozkin <sberyozkin@gmail.com> Mon, 03 November 2014 11:00 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062B11A007F for <oauth@ietfa.amsl.com>; Mon, 3 Nov 2014 03:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 VSwr98CVAjwH for <oauth@ietfa.amsl.com>; Mon, 3 Nov 2014 03:00:51 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFE41A006F for <oauth@ietf.org>; Mon, 3 Nov 2014 03:00:50 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id l18so12215681wgh.10 for <oauth@ietf.org>; Mon, 03 Nov 2014 03:00:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LgD4XmUp+wXF+iqlHj/p/wNueRaNu/GAetLp2YsQ6SQ=; b=Iv49pEBX/ejts/IULEfkaiQ7sQcFlAMjmQT1NGEDPPU8mFaETU1KKnWooNOEKY2ETx jW4GNrkKmKiGbARWNAyaVH3CZ/EoQjM8zGKqlLJeTw+9PjUCZCKuVdGOllFZw9KaFknQ bWCdj6j4dGwOHTHMRyocsfiuSdZJUj/2cRInsZLDu+roOT+2ZKXbaZ6lxl59h42e2nuU 4yAUnqh2OW3DsFn+HHw+m13hu4/sV7QHzM30aN2j/YawjAyTx4gG+iFW4yoz09TmOgjL eK7j5Hlv7VKJA5dxAHjKFnBlh9bYEhy2LsPqlbGQ7Zp9ZjODFjVG9JFl/SXDWVa6bqpG fIyw==
X-Received: by 10.194.192.73 with SMTP id he9mr1507308wjc.125.1415012449473; Mon, 03 Nov 2014 03:00:49 -0800 (PST)
Received: from [192.168.2.7] ([109.255.82.67]) by mx.google.com with ESMTPSA id n4sm21426113wjb.40.2014.11.03.03.00.48 for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Nov 2014 03:00:48 -0800 (PST)
Message-ID: <5457604F.7030100@gmail.com>
Date: Mon, 03 Nov 2014 11:00:31 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <545704EE.8080200@mit.edu>
In-Reply-To: <545704EE.8080200@mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lp3w5BdTrYXig-ZteYXTcEkPq7E
Subject: Re: [OAUTH-WG] End User Authentication using OAuth 2.0
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Nov 2014 11:00:53 -0000

Hi Justin,
On 03/11/14 04:30, Justin Richer wrote:
> As of earlier this evening, I've published the article that we've been
> working on about dealing with OAuth and end-user authentication. It's
> available here:
>
> http://oauth.net/articles/authentication/
>
> Huge thanks to everyone who commented on the text, both here on the list
> and last week at IIW. If there are edits to be made, either reply here
> or just make a pull request directly from GitHub. It's not an RFC, we
> can keep editing it. :)
Thanks for your help. Nice article indeed.

Something I've been planning to ask, sorry if it is off topic - may be 
it is better be posted elsewhere, just let me know please, the actual 
question is here for now:

OIDC can help Clients ask for the permissions to access the user's 
identity info plus some other info this Client actually needs to have in 
order to do something useful for the user at the same time. This is one 
of the distinguishing features of OIDC. I guess a good example would be 
an "openid profile calendar" scope, where a 'calendar' scope is about 
the Client being able to access the user's calendar.

What is not clear here is how it all fits into a typical sign on process 
followed by some service offerings. Suppose we have a ReservationService 
Client. When the user goes to the ReservationService's web site which 
supports a sign on via Google or other OIDC IDP, the user is obviously 
not redirected immediately to Google with "openid profile calendar" 
scope already set, the user would see some kind of Sign On Welcome Page 
first.

After the user completes the sign on process, the OIDC RP would validate 
id_token, may be get UserProfile, and then the session would begin and 
the service will offer the user an option to do some reservation which 
requires a Client to have an access token allowing it to get to the 
user's calendar.

One question here is really how it can be aligned with the OIDC feature 
allowing IDP/AS to ask during the user signing on with OIDC IDP for 
multiple permissions such as "openid profile calendar" at the same time.

I can only imagine that for this to work, the Sign On Welcome Page would 
already have a script with the "openid profile calendar" scope set, so 
when the user clicks some 'Sign In' button, the user would be asked at 
the OIDC IDP site to let the Client access "the profile info and the 
calendar info".

That is probably how it should flow. If so, then it is obvious OIDC RP 
should share a session state with the actual ReservationService client 
because a signed on user redirected back to it from OIDC IDP/AS won't 
have reserved something for it straight away, ReservationService would 
only now ask the signed on user some questions re the reservation 
details. And the only way ReservationService can complete the 
reservation is for it to use an access token OIDC RP received when it 
itself accessed the OIDC UserProfile endpoint.

Effectively we are talking about OIDC RP sharing an access token via a 
session state with the Client in this case. Note I'm referring to the 
case where the Client wants to ask both OIDC related and its own 
application specific permissions such as "openid profile calendar" and 
the fact that the end user would be typically be exploring 
ReservationService site in two steps, sign on first, ask for the 
reservation service next.

Does it make sense at all ? If yes, what, if anything, can be 
recommended in this case where an access token is to be shared between 
OIDP RP and the actual Client ?

Thanks, sorry for a long message

Sergey






>
> In the process of putting this together for the site, I also created an
> "Articles" structure on the site so that if there are other topics we
> want to add, we (the community, not just the WG) can do so.
>
>   -- Justin
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth