Re: [OAUTH-WG] Session cookies in OAuth2 flow

Andrei Shakirin <ashakirin@talend.com> Fri, 25 April 2014 15:36 UTC

Return-Path: <ashakirin@talend.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 C460C1A0538 for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 08:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level:
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, 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 B05FwgKYRKuo for <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 08:36:09 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [74.201.97.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8861A04F1 for <oauth@ietf.org>; Fri, 25 Apr 2014 08:36:09 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8C3867B2FE7; Fri, 25 Apr 2014 11:36:01 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from S10HUB003.SH10.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A0C227B2FC2; Fri, 25 Apr 2014 11:36:00 -0400 (EDT)
Received: from S10BE002.SH10.lan ([::1]) by S10HUB003.SH10.lan ([::1]) with mapi id 14.01.0379.000; Fri, 25 Apr 2014 11:36:01 -0400
From: Andrei Shakirin <ashakirin@talend.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Session cookies in OAuth2 flow
Thread-Index: Ac9f1m601wyijPx7QUKZAdgpumsSswAfcZMAAAAQz7AAEtf8AAAICd4g
Date: Fri, 25 Apr 2014 15:36:01 +0000
Message-ID: <D225CD69196F3F4A9F4174B2FCA06F8811EC8367@S10BE002.SH10.lan>
References: <D225CD69196F3F4A9F4174B2FCA06F8811EC7E92@S10BE002.SH10.lan> <8CE5B8B4-5CFB-4E1C-B1EC-06D2F0217ED8@adobe.com> <D225CD69196F3F4A9F4174B2FCA06F8811EC81D7@S10BE002.SH10.lan> <7EF3EC88-B32C-4858-8570-B142A6EEE96C@ve7jtb.com>
In-Reply-To: <7EF3EC88-B32C-4858-8570-B142A6EEE96C@ve7jtb.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [95.91.233.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GIVPCfvqusmHPMZu7-3J6ytpA7U
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 15:36:12 -0000

Hi John,

Thanks a lot for your explanation!

I am a bit confused regarding "state" parameter and cookies. I thought that "state" is included in redirection URI for user-agent and verified by client when Authorization server redirects user-agent back.
It is a way to bind authorization request to response (4.1. Authorization Code Grant, steps (A) and (C)).
Are the cookies really necessary in this case? Can they provide additional protection in case if redirect URI manipulated?

Regards,
Andrei.


> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Freitag, 25. April 2014 14:03
> To: Andrei Shakirin
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
> 
> Yes the server can be stateless, though it may need to store client credentials
> and user to validate against, and refresh token grants etc.
> 
> 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.
> 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,
> >
> > 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.
> >
> > Regards,
> > Andrei.
> >
> >> -----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
> >>
> >> hi Andrei,
> >>
> >> AFAIU session cookie management is beyond the scope of the OAuth2
> >> specification.
> >>
> >> regards
> >>
> >> antonio
> >>
> >> On Apr 24, 2014, at 6:39 PM, Andrei Shakirin <ashakirin@talend.com>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> 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
> >>>
> >>> 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.
> >>>
> >>> Is this correct?
> >>>
> >>> Regards,
> >>> Andrei.
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth