[OAUTH-WG] Using IdToken instead of Access token

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 03 August 2016 10:08 UTC

Return-Path: <sberyozkin@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 B795112D0BA for <oauth@ietfa.amsl.com>; Wed, 3 Aug 2016 03:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dgw5ntz3B_ZE for <oauth@ietfa.amsl.com>; Wed, 3 Aug 2016 03:08:31 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 8E22712B014 for <oauth@ietf.org>; Wed, 3 Aug 2016 03:08:31 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id o80so328427111wme.1 for <oauth@ietf.org>; Wed, 03 Aug 2016 03:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=yQ5ZvCU3u7h14ggMJYRZt+gTHQx2Ea5tHpWvgJCc4GQ=; b=wVdfAAN3LYkcYJfnHgSwMjcVzv+Ghx/f2QU6V9imvZNV+viSRKz9RDQ70AGwL2loOg g2QlRaYVp9uV1LmAlO7TYs3BHVSSNYCfdLx7gerWpjhqHaBVs+LiXas+XeEzTWPTYdKk S4pHPAc9+9xNbH3iyfz/JCPx8qpFBoN7VNQ9bYUxUHeS3p3tD3HIdDFChSn7beBIQl5s 6BkCJ6sIJdYySzZQGeG/0Q5HKtJm2RhEia92lyPF8fe49zrRR0SMvXm/LTJ2sbtHttlz wlsmj3+5uwHyVeQ+vNcp3B/BcymNBKORsrK//rBTP7MhhrpJiNKqFDsduBbTGU9wuF+9 tZCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yQ5ZvCU3u7h14ggMJYRZt+gTHQx2Ea5tHpWvgJCc4GQ=; b=Cy3B4OU4XsGjtb5+RAgVpd/ENMwOzkcRv7mBHcgnfffrrcehkyA+i81KxHj/KriUGT Ei3GQPMHc/fpJBinDO4wmMFzmhpSfZpAeKK4bLYJXIhSuYOotyNW3kZvSGJ8BPz18xng XGHEGFuo/PdW/2xXA2dgM+KTKkhsTTn+8q4latgvBsiOfz2rjbzuLtYxFC854mDU6tSZ n8N1mC6rW7H3qdYnJt1OEXjaK+3nK2gEIdnHmpvKXInZKvemPBbeHqfiHpwa/D39d3Zu 3VbVYGg2IjeigUxY+J7hiZhVD3ORY4hZ6QaUgHNQ4f3HcTb9GJ++W3jSuiPI3sy7jvWL UfTQ==
X-Gm-Message-State: AEkooutJwth2C3W97IsLOQiipkjXaxOmWxWgKViQiqG55Izib5OXZzkN+Eeg62FrXtxBNA==
X-Received: by 10.28.64.86 with SMTP id n83mr69886196wma.52.1470218909845; Wed, 03 Aug 2016 03:08:29 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id w129sm7317581wmd.9.2016.08.03.03.08.28 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 03:08:28 -0700 (PDT)
To: "oauth@ietf.org" <oauth@ietf.org>
References: <5795F109.9040403@gmx.net> <DM5PR03MB2441ACA5B240108C320DFABAA60D0@DM5PR03MB2441.namprd03.prod.outlook.com> <CA+k3eCR_EFdA4Zdiwfm65nq99gVYg8eKrC6x7EB_OG=20y4=WA@mail.gmail.com> <beaaa4f8-7f5e-8f1d-d0bd-6aa5b418ccdc@connect2id.com>
From: Sergey Beryozkin <sberyozkin@gmail.com>
Message-ID: <b026f4fc-3e08-4e00-02c3-84be2dc4b2bb@gmail.com>
Date: Wed, 03 Aug 2016 11:08:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <beaaa4f8-7f5e-8f1d-d0bd-6aa5b418ccdc@connect2id.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/18Oa7MaCj_9nUocC_v7eJMz25Ck>
Subject: [OAUTH-WG] Using IdToken instead of Access token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 03 Aug 2016 10:08:35 -0000

Hi All

I hope this question is better suited for this list. Will have no 
problems redirecting it to the openid-connect list instead.

Consider a user working with the client web application (OIDC RP) which 
authenticates the user with the OIDC authorization code flow at the end 
of which the client gets AccessToken + IdToken. Next the user requests 
something from the client which needs to access the RS to complete this 
request.

And the idea is to have the client pass IdToken to RS and use various 
user claims inside this IdToken to enforce the access control at the RS 
level. My position it is likely wrong but I guess I may be missing 
something that will be either in favor or against it.

The reason I think it is wrong is that if the client is using a code 
flow then the right approach for staying within the OAuth2 'world' is to 
use the access token to talk to RS and use IdToken only for the purpose 
of interacting with the user. The access token represents a proper user 
authorization and can have the extra scopes in addition to "oidc" which 
RS can depend upon in its access control restrictions.

Next I'm arguing that if the IdToken is used instead then it is the case 
of the client impersonating the user. And refer to the STS for the REST 
of Us draft (I have a separate series of question on that draft). I'm 
saying the impersonation can work but ignoring the access tokens 
completely will make the overall solution much less flexible.

I'd like to ask for some advice/guidance:

- Is it a good idea at all for the client to use IdToken instead of 
AccessToken as explored above ? I suppose it can work, in the code flow 
the client gets the access token which, by default, only allows to 
access UserInfo. Perhaps the client impersonating IdToken for the 
purpose of accessing RS is not too bad after all.

- Assuming the impersonation is OK, what is the right criteria for the 
client to choose to work with IdToken instead of the access token when 
accessing the immediate RS. It seems like if the impersonation is OK for 
the client to do then why have access tokens at all...

- Assuming the impersonation is OK, does STS For the REST of Us shows 
the right and the only way it needs to be done ? I can imagine how it 
will work for the web app clients, but what about Implicit Clients.

Many thanks, Sergey