Return-Path: <ve7jtb@ve7jtb.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 BAE251A048D for <oauth@ietfa.amsl.com>;
 Fri, 25 Apr 2014 05:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level: 
X-Spam-Status: No,
 score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
 FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 zSJGG9OfZ7EM for
 <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 05:03:15 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com
 [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 412721A048C for
 <oauth@ietf.org>; Fri, 25 Apr 2014 05:03:14 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id m5so2263941qaj.25 for
 <oauth@ietf.org>; Fri, 25 Apr 2014 05:03:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
 s=20130820;
 h=x-gm-message-state:content-type:mime-version:subject:from
 :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to;
 bh=m4fLkaPty45QC4ckv/XR/14NzuIE9Uk7HQ4748OOpZs=;
 b=BFc2SHlVHabLdnMjHKURRwaptMnUD8nwtUzVe3T4ygSTdYf2GXs8mCJgfHVXmAcFyS
 ezYaYH4wb60EhwxwEn4vcQkV+6/89Ks2huRV0tzFB1MdEXPZlyR/0HGNcWBFcGRsE85u
 3FNoyRfqDGoFRZNiw56HteRWOjUF5FnjQ2jxNfdvTeJpEElzyu3/RsJB2bafJKw4p2Th
 WtZ1Gw07E0sTF5/gHyqdWs1xlGYMz+s5t4686xinlcpE/q0mHQ0GxmoVwlEvodoQm7hC
 pvAIXfyLjDPv6N9ArohP7vwq9+yGgbE0tijfbBhsHSWMGwQ/ygLMPLs61nW+9hKgFlqL 67rQ==
X-Gm-Message-State: ALoCoQldWTCh2AvwPDQALQuIKY7xwAPFYRaPcq91Uo916rJ0fJNQzH1bNI+dOKXysfiOAFRPnQlH
X-Received: by 10.140.86.71 with SMTP id o65mr10036583qgd.67.1398427388497;
 Fri, 25 Apr 2014 05:03:08 -0700 (PDT)
Received: from [192.168.0.200] ([201.188.125.93]) by mx.google.com with
 ESMTPSA id 11sm9313704qgv.20.2014.04.25.05.03.06 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 25 Apr 2014 05:03:07 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <D225CD69196F3F4A9F4174B2FCA06F8811EC81D7@S10BE002.SH10.lan>
Date: Fri, 25 Apr 2014 09:03:06 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7EF3EC88-B32C-4858-8570-B142A6EEE96C@ve7jtb.com>
References: <D225CD69196F3F4A9F4174B2FCA06F8811EC7E92@S10BE002.SH10.lan>
 <8CE5B8B4-5CFB-4E1C-B1EC-06D2F0217ED8@adobe.com>
 <D225CD69196F3F4A9F4174B2FCA06F8811EC81D7@S10BE002.SH10.lan>
To: Andrei Shakirin <ashakirin@talend.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/97vfE-hEajm9liFg7EpZeOOzde4
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
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: Fri, 25 Apr 2014 12:03:17 -0000

Yes the server can be stateless, though it may need to store client =
credentials and user to validate against, and refresh token grants etc. =20=


The "state" parameter allows the client to maintain some state =
information across the Oauth authorization request and response.

Part of the use of that state information by the client allows it to =
protect itself from having authorization requests initiated by 3rd =
parties that is what Sec 10.12 is talking about. =20
In that case the client can save state in a browser cookie or in the =
server and use that to validate the returned state value to assure =
itself that the authorization request came from itself.

John B.

On Apr 25, 2014, at 4:08 AM, Andrei Shakirin <ashakirin@talend.com> =
wrote:

> Hi Antonio,
>=20
> Thanks for your quick answer.
> Important for me is that OAuth2 doesn't force to store client or =
user-agent states in the authorization server, so authorization server =
can be stateless and is not obligated to introduce the sessions at all.
>=20
> Regards,
> Andrei.
>=20
>> -----Original Message-----
>> From: Antonio Sanso [mailto:asanso@adobe.com]
>> Sent: Freitag, 25. April 2014 09:02
>> To: Andrei Shakirin
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
>>=20
>> hi Andrei,
>>=20
>> AFAIU session cookie management is beyond the scope of the OAuth2
>> specification.
>>=20
>> regards
>>=20
>> antonio
>>=20
>> On Apr 24, 2014, at 6:39 PM, Andrei Shakirin <ashakirin@talend.com> =
wrote:
>>=20
>>> Hi,
>>>=20
>>> My name is Andrei Shakirin, I am working with OAuth2 implementation =
in
>> Apache CXF project.
>>> Could you please help me to verify my understanding regarding of =
using
>> session cookies in OAuth2 flow.
>>> OAuth2 specification mentions session cookies in:
>>> 1) Section 3.1. Authorization Endpoint as possible way to =
authenticate
>> resource owner against authorization server
>>> 2) Section 10.12. Cross-Site Request Forgery as possible attack =
where end-
>> user follows a malicious URI to a trusting server including a valid =
session cookie
>>>=20
>>> My current understanding is:
>>> a) using sessions between user-agent and authorization server is =
optional and
>> authorization server is not obligated to keep user state (in case if =
user-agent
>> provide authentication information with every request).
>>> b) in case if sessions are used (because of any reasons), =
authorization server
>> have to care about additional protection like hidden form fields in =
order to
>> uniquely identify the actual authorization request.
>>>=20
>>> Is this correct?
>>>=20
>>> Regards,
>>> Andrei.
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

