Re: [OAUTH-WG] Report an authentication issue

John Bradley <> Thu, 28 June 2012 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF31921F8513 for <>; Thu, 28 Jun 2012 13:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.436
X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ec78y4ACIQJK for <>; Thu, 28 Jun 2012 13:48:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 573E121F8512 for <>; Thu, 28 Jun 2012 13:48:03 -0700 (PDT)
Received: by yhfq11 with SMTP id q11so2738999yhf.15 for <>; Thu, 28 Jun 2012 13:48:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SnfyFwmcB0D1z1MAP4Jxjg6ClE5LyaUV7atiNQ4+gU4=; b=HiIgr4k1y0czTX2eKCnhMN41QmPpn5O4hg+7Ra4XThRzzBTaDwIDIOFfSH9daaQ0Bm mu4UFj8h2i5OTj3wnALFLBik//hSCKWarKoaSA6m/+P15NOx/4o329V83ViWIFOjpx9r hJ0OtdtOtJoNnsbNM7CzIBxHiC9d3QTVyiCr+LU4ka2e39hTgMyCE66GAKzUFv8pLgxl TJtwYpHor5oDWDlc7qHhe21Os7hpoxCkdbHmIiJBdriLKXU9aCboKTt7MwNh8e1b/VW2 phDMsyAPVJB1tbU9tSmBLbVsc4eJ5PSVIswD3gqDVDgCR3/GYG+jiYRmYPQ2ia2kJajq 9/Lw==
Received: by with SMTP id c61mr5702578yhk.130.1340916483056; Thu, 28 Jun 2012 13:48:03 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id d10sm528709anm.17.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 13:48:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_6681819B-FB75-4043-A2FD-4872338C9CEF"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <>
In-Reply-To: <>
Date: Thu, 28 Jun 2012 16:47:54 -0400
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <CABzCy2DzmNgmMALNfc1qp95fwD2WULb-49Dk> <>
To: Lewis Adam-CAL022 <>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk/z12DOVUeEXs2vqyN8B1POtBIxuhY6K6Z0y1+0f2bn1nxYe78o9hG5IYLpwYXHYCfOXk4
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 20:48:05 -0000


This is getting tangled up in semantics.

The AS authenticates the user and Authorizes the client (native App) to access the protected resource (video server) via issuing it a access token, or a authorization code that it can trade at a token endpoint for a refresh_token and access_token.

At that point the client has no notion of who the user is unless a openID Connect id_token was also sent.  I suspect that the video player app may not care who the person, only what it can access.

The App then uses its access token to prove that it was delegated access to the server by some person (Resource owner in OAuth speak).  
In your STS example you call this Authentication, but in OAuth it is Authorization.  The client is the one being authenticated to the resource via the token.
The User is Authenticated to the AS.   The same trust chain exists it just uses different terms.

That token can be structured like the id_token is, but there is an important difference.  The access token's audience is the resource server and the id_token's audience is the client.
That is one of the reasons they are separate.

This looks like a relatively strait forward OAuth use case to me,  you can probably also use opaque tokens with a AS STS and some caching logic at the RS if you want to keep the token size down.

John B.

On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote:

> Hi Nat,
> Starting from a standalone 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. 
> <acl> yes … that *and* to authenticate the user in the first place.  So again, my access_token will actually look like the Connect id_token.  I would even prefer to use the id_token, except that it violate the spirit of Connect to pass the id_token to the RS (e.g. it was only meant for consumption by the client).
> My problem space can be distilled to something very simple.  
> -          We come from a SOAP API world where we use WS-Trust to secure the SOAP API calls.  WS-Trust makes it very simple for a WS-* client to collect the user’s primary credentials, exchange it for a (SAML) bearer token via the STS, and embed that bearer token in SOAP-based API calls to the WS-* server. This is most definitely *authentication*
> -          We are moving to a RESTful API world.  I just want to be able to do the same thing as above. How do I enable my REST-based client to collect the user’s password, exchange it for a (JWT) bearer token via the STS, and embed that bearer token in RESTful API calls to the REST-based server, such that the REST-based server can *authenticate* the client?  
> (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. 
> <acl> that would be nice, but most of my users will be using passwords in the beginning, so this is not an option.  I’m using the literal definition of bearer token here, taken straight out of the OAuth bearer token spec, e.g. “Any party in possession of a bearer token (a "bearer") can use it to get
> access to the associated resources (without demonstrating possession of a cryptographic key).”
> (3) In addition, the RS may not be able to talk to AS directly.
>      [Well, this is one of my use case anyways.] 
> <acl> Right … this is why I am now looking at structured JWTs.
> (4) In some cases, the client may not be able to communicate with AS directly at the time of RS access. [ditto]
> <acl> Right again, we have disaster scenarios to think about where the AS might not be reachable.  but this is a use case for next steps.  Trying to walk before we fly here :-)
> _______________________________________________
> OAuth mailing list