Re: [OAUTH-WG] Report an authentication issue

Nat Sakimura <> Thu, 28 June 2012 03:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86A9F21F87C0 for <>; Wed, 27 Jun 2012 20:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.438
X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v8iGIwBUSLAd for <>; Wed, 27 Jun 2012 20:33:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3FA1521F87C7 for <>; Wed, 27 Jun 2012 20:33:59 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1713198bkt.31 for <>; Wed, 27 Jun 2012 20:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y4Xqgxt/DzltDpZrqBPlMjLze7pLRGpFK8sU4tIDhDY=; b=iPamiAd/J/iqNBzeWm1++mB0a57zQHiI2OYOLET5eetxJ7pIqSslS8vxSrxY6p+TRF N1raxAGS1DOcMKqOGW3dOZVk9y3/H0YD1IzGjH/kXJyoskRk7GCHmh3euZQ5+kADv1Uw J077c1FgR0tHIomSzUDEgDzsY3Ovl0TQOApXdghYt1+NwhHKksoonKsEaWevelYUDq/p CQpqjUlaY7dCpCGrBpbJdEjARlG0MeCnuJDij4uM353lmc01DXnxRNRmLJMtFSzS3j0U D40SINT0U398/bc7gEB29+jUFJ9bAo5Kjbhtal8djQhPLEbcqUJ0Ca9XNEKkJRDOeoEd 668g==
MIME-Version: 1.0
Received: by with SMTP id iv17mr73208bkc.118.1340854438247; Wed, 27 Jun 2012 20:33:58 -0700 (PDT)
Received: by with HTTP; Wed, 27 Jun 2012 20:33:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 28 Jun 2012 12:33:58 +0900
Message-ID: <>
From: Nat Sakimura <>
To: Lewis Adam-CAL022 <>
Content-Type: multipart/alternative; boundary="001517402de67cbdb504c380009f"
Cc: "" <>
Subject: Re: [OAUTH-WG] Report an authentication issue
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Jun 2012 03:34:00 -0000

On Tue, Jun 26, 2012 at 1:54 AM, Lewis Adam-CAL022 <> wrote:

> ** **
> I think the above just really drives home the fact that if OAuth is to be
> used for securing enterprise API calls in a post-SOAP world, something
> needs to be stated more explicitly.  OAuth was not designed to provide
> authentication of the user to the RS.  But it seems we all agree that it
> can be profiled to do so.  Connect is supposed to address authentication,
> but only from the view of the client, and not the RS.  Only the access
> token goes to the RS, so if we want to authenticate a user to the RS, then
> we’re back to OAuth, since Connect doesn’t intend to send the id_token to
> the RS.  Nat mentioned that it “could,” but I haven’t seen that as part of
> the Connect specs thus far.  ****
> ** **
> There is **clearly** confusion around whether OAuth is to be used as
> authentication or not, and I think this
thread has shown that.  If I’m going to deploy OAuth for Authentication,
> then I really need a spec to point to (when my customers ask) that says it
> can be used that way, especially with all the “OAuth is NOT authentication”
> blog posts floating around in cyberspace these days.

Confusion is true. The fact is that OAuth by itself is incapable of
providing user authentication result to the resource server (nor the client
for that matter). It in fact is completely out of scope. OAuth is an access
delegation (aka authorization) mechanism. It has nothing to say about who
uses the token. Assuming the user of the access token is the resource owner
is a false assumption.

> ****
> ** **
> I’m thinking two things: ****
> **1)      **it would at least be worthwhile to document this use case,
> and maybe the OAuth use cases draft would be a good place to capture it.
Starting from a stand alone use case would be good.
My impression (I may be wrong) is that your requirement is to be able to

(1) Log the user identifier of the person who is accessing the resource at
the resource server for the audit etc. purposes.
(2) Do the holder of the key so that the RS is sure that the person
accessing with the access token
     is really the person.
(3) In addition, the RS may not be able to talk to AS directly.
     [Well, this is one of my use case anyways.]
(4) In some cases, the client may not be able to communicate with AS
directly at the time of RS access. [ditto]

Are these correct?

FYI, (2) has been a work item for John Bradley for sometime.
For (1), (3), (4), OIDF's CX working group has been working on it.
The Working Group currently is dormant waiting for the Connect to finish
so that it can leverage it. (Good portion of Connect actually came from CX
work results.)

> **2)      **maybe a stand alone, informational draft would also be a good
> idea, especially if we all agree that it’s only a profile of OAuth, and
> does not require any technical changes to the core draft.  Something that
> talks outright about an enterprise-centric world, rather than the user
> RO-centric world that OAuth was really written around.  This might give
> future generation of Enterprise folks like myself an easier time.
That's essentially what we are doing with OpenID Connect, though not
informational document but as a normative standard at OIDF.



> ****
> ** **
> ** **
> Thoughts?****
> -adam****
> ** **
> **