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

From: Andrei Shakirin <[email-masked]>
Date: Thu, 24 Apr 2014 16:39:45 +0000

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.

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 25 Apr 2014 07:01:40 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Andrei Shakirin <[email-masked]>
Date: Fri, 25 Apr 2014 07:08:10 +0000

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:[email-masked]]
> Sent: Freitag, 25. April 2014 09:02
> To: Andrei Shakirin
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
> 
> hi Andrei,
> 
> > 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
> >
> > 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.
> >

---

From: John Bradley <[email-masked]>
Date: Fri, 25 Apr 2014 09:03:06 -0300

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.

---

From: Andrei Shakirin <[email-masked]>
Date: Fri, 25 Apr 2014 15:36:01 +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.

> From: John Bradley [mailto:[email-masked]]
> Sent: Freitag, 25. April 2014 14:03
> To: Andrei Shakirin
> Cc: [email-masked]
> 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.
> 
> > 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.
> >
> >>> 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.
> >> authorization server is not obligated to keep user state (in case if
> >> user-agent provide authentication information with every request).
> >> have to care about additional protection like hidden form fields in
> >> order to uniquely identify the actual authorization request.
> >>>
> >>> Is this correct?
> >>>
> >>> Regards,
> >>> Andrei.
> >>>

---

From: John Bradley <[email-masked]>
Date: Fri, 25 Apr 2014 13:23:23 -0300

For cross site request forgery you need to validate the value in state somehow.   You could store the value in the browser session, or relate it somehow to session information in the server.

Making up a random number in the request and checking that there is a random number in the response won't help.
Even signing the value of the state is not super useful as the the attacker could just separately get a state value from another authn request and use that in there cross site request request.

The cookie or hash of some other TLS bound session cookie allows the client to detect the XRSF attack without using server side state on the client.

John B.

---

From: Andrei Shakirin <[email-masked]>
Date: Sat, 26 Apr 2014 11:52:17 +0000

Hi John,

Thanks for explanation, so basically "state" binds the redirected request to user-agent authentication state.

Do you think the following way to check "state" is safe enough as well?
1. The client authenticates user-agent by every request (for example using Basic or Digest over SSL) 
2. The client generates a random state and stores it into kind of hashtable (user id -> list of states) for every initial request.
3. Client injects generated state into redirect URL as query parameter.
4. When Authorization server redirects user-agent back to the client using redirect URL, client authenticates user-agent and compares the state received with request (it was injected into URL) with value from internal hashtable based on user identity.
5. Used state is removed from hashtable to prevent repeatable using.

Thanks in advance,
Andrei.

> Sent: Freitag, 25. April 2014 18:23
> To: Andrei Shakirin
> Cc: [email-masked]
> For cross site request forgery you need to validate the value in state somehow.
> You could store the value in the browser session, or relate it somehow to
> session information in the server.
> 
> Making up a random number in the request and checking that there is a
> random number in the response won't help.
> Even signing the value of the state is not super useful as the the attacker could
> just separately get a state value from another authn request and use that in
> there cross site request request.
> 
> The cookie or hash of some other TLS bound session cookie allows the client to
> detect the XRSF attack without using server side state on the client.
> 
> John B.
> 
> 
> > 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.
> > Are the cookies really necessary in this case? Can they provide additional
> protection in case if redirect URI manipulated?
> >
> > Regards,
> > Andrei.
> >
> >
> >> 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.
> >>
> >> states in the authorization server, so authorization server can be
> >> stateless and is not obligated to introduce the sessions at all.
> >>>
> >>> Regards,
> >>> Andrei.
> >>>
> >>>>> My name is Andrei Shakirin, I am working with OAuth2
> >>>>> implementation in
> >>>> Apache CXF project.
> >>>> authorization server is not obligated to keep user state (in case
> >>>> if user-agent provide authentication information with every request).