Subject: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 09:26:29 +0800

Dear All:

I have a question in the section 1.3.1. Authorization
Code in rfc6749 The OAuth 2.0 Authorization Framework.

It tells "which
in turn directs the resource owner back to the client with the
authorization code."

Who can let me know the reason why is the
authorization code sent to client through a redirection in resource
owner's agent? Any security implications?

Is it possible to let the
authorization server send the authorization code to the client directly
(not through resource owner's user-agent)?

Best Regards
Brent

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 9 Jan 2013 11:57:50 +0530

Hi Brent,

Few points, why this doesn't create any security implications..

1. Authorization server maintains a binding to the Client, who the token
was issued to. To exchange this to an Access token client should
authenticate him self.
2. Code can only be exchanged once for an acces token.

Thanks & regards,
-Prabath

On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <[email-masked]>wrote:

> **
>
> Dear All:
>
> I have a question in the section 1.3.1. Authorization Code in rfc6749 The
> OAuth 2.0 Authorization Framework.
>
> It tells "which in turn directs the resource owner back to the client with
> the authorization code."
>
> Who can let me know the reason why is the authorization code sent to client
> through a redirection in resource owner's agent?  Any security
> implications?
>
> Is it possible to let the authorization server send the authorization code
> to the client directly (not through resource owner's user-agent)?
>
> Best Regards
> Brent
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com

---

From: [email-masked]
Date: Wed, 9 Jan 2013 14:36:37 +0800

Then why not let auth code be sent directly from AS to Client?

Just want to inform RO that an auth code has been dilivered to Client? 

[email-masked] 写于 2013-01-09 14:27:50:

> 1. Authorization server maintains a binding to the Client, who the 
> token was issued to. To exchange this to an Access token client 
> should authenticate him self.

> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <[email-masked]
> > wrote:
> Dear All:
> 
> I have a question in the section 1.3.1. Authorization Code in rfc6749 
> The OAuth 2.0 Authorization Framework.
> 
> It tells "which in turn directs the resource owner back to the client 
> with the authorization code."
> 
> Who can let me know the reason why is the authorization code sent to 
> client through a redirection in resource owner's agent?  Any security 
> implications?
> 
> Is it possible to let the authorization server send the authorization 
> code to the client directly (not through resource owner's user-agent)?
> 
> Best Regards
> Brent
> 

> http://RampartFAQ.com_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 9 Jan 2013 12:17:19 +0530

On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <[email-masked]> wrote:

> Dear Prabath:
>
> Thank you very much for your responses :-)
>
> However, I am still not quite sure why the authorization code must be
> sent to the client through the RO's user-agent?
>

One reason I see is, bringing the authorization code via User Agent - links
the user request to the authorization code. If AS directly sends the code
to the Resource Server the mapping between the user request and the code is
broken.

Thanks & regards,
-Prabath

>
> Best Regards
> Brent
>
> 2013/1/9 Prabath Siriwardena <[email-masked]>:
> > Prabath
>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 14:47:16 +0800

Dear Prabath:

However,
I am still not quite sure why the authorization code must be
sent to the
client through the RO's user-agent?

Best Regards
Brent 

On Wed, 9 Jan
2013 11:57:50 +0530, Prabath Siriwardena wrote: 

> Few
points, why this doesn't create any security implications.. 
> 1.
Authorization server maintains a binding to the Client, who the token
was issued to. To exchange this to an Access token client should
authenticate him self. 
> On Wed, Jan 9,
2013 at 6:56 AM, cspzhouroc wrote:
>> I have a
question in the section 1.3.1. Authorization Code in rfc6749 The OAuth
2.0 Authorization Framework.
>> 
>> It tells "which in turn directs the
resource owner back to the client with the authorization code."
>> 
>> Is it possible to let the authorization server send
the authorization code to the client directly (not through resource
owner's user-agent)?
>> OAuth mailing list
[email-masked] [1]
>> https://www.ietf.org/mailman/listinfo/oauth [2]
>

> http://blog.facilelogin.com [4]
> http://RampartFAQ.com [5]

Links:
------
[1] mailto:[email-masked]
[2]
https://www.ietf.org/mailman/listinfo/oauth
[3]
mailto:[email-masked]
[4] http://blog.facilelogin.com
[5]
http://RampartFAQ.com

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 14:49:00 +0800

Dear SuJing:

If it is the only reason, why we send the
authorization code to the
client directly and send another notification
without the
authorization code to the RO. This way can mitigate the
chance that
the authorization code is exposed to the RO's user-agent,
hence
protecting the authorization code from leaking to possible
attackers
in a higher security levle.

Best Regards
Brent 

On Wed, 9
Jan 2013 14:36:37 +0800, [email-masked] wrote: 

> Then why not
let auth code be sent directly from AS to Client? 
> Just want to
inform RO that an auth code has been dilivered to Client? 
>> On Wed,
Jan 9, 2013 at 6:56 AM, cspzhouroc 
> > It tells "which in
turn directs the resource owner back to the client 
> > Who can let me know the reason why is the
authorization code sent to 
> > Is it possible
to let the authorization server send the authorization 
> > code to the
client directly (not through resource owner's user-agent)?
> > Best
Regards

> > Mobile : +94
71 809 6732 
OAuth mailing list

---

From: [email-masked]
Date: Wed, 9 Jan 2013 14:51:35 +0800

I am just guessing......expecting others answer here. 
On the other hand, auth code exposed to RO does not have security 
implication, 
as far as I know:
1. if auth code is transported in plaintext, it should require CLient 
authentication to use it.
2. if auth code  do not need Client authentication , auth code could be 
sent in encryption

Peng Zhou <[email-masked]> 写于 2013-01-09 14:42:09:

> Dear SuJing:
> 
> If it is the only reason, why we send the authorization code to the
> client directly and send another notification without the
> authorization code to the RO. This way can mitigate the chance that
> the authorization code is exposed to the RO's user-agent, hence
> protecting the authorization code from leaking to possible attackers
> 2013/1/9  <[email-masked]>:
> >

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 14:52:31 +0800

Dear Prabath: 

But is it possible to include the the mapping
between the user request and the code in the message that the AS sends
to the client directly? 

Best Regards 

Brent 

On Wed, 9 Jan 2013
12:17:19 +0530, Prabath Siriwardena wrote: 

> On Wed, Jan 9, 2013 at
12:09 PM, Peng Zhou wrote:
> One reason I see is, bringing the authorization
code via User Agent - links the user request to the authorization code.
If AS directly sends the code to the Resource Server the mapping between
the user request and the code is broken. 
-Prabath 
>> 2013/1/9 Prabath
Mobile : +94 71 809 6732 
> 
> http://blog.facilelogin.com [3]
>
http://RampartFAQ.com [4]

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3]
http://blog.facilelogin.com
[4] http://RampartFAQ.com

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 9 Jan 2013 12:24:41 +0530

On Wed, Jan 9, 2013 at 12:22 PM, cspzhouroc <[email-masked]>wrote:

> **
>
> Dear Prabath:
>
>
>
> But is it possible to include the the mapping between the user request and
> the code in the message that the AS sends to the client directly?
>

Nope.. We need the mapping between the request and code.. Adding user name
or any identifier to the message sending from AS to Client won't help.
Because browser request has to identify it self.

Thanks & regards,
-Prabath

>
>
> Best Regards
>
> Brent
>
>
>
> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:
>
>
>
>  One reason I see is, bringing the authorization code via User Agent -
> links the user request to the authorization code. If AS directly sends the
> code to the Resource Server the mapping between the user request and the
> code is broken.
>  Thanks & regards,
> -Prabath
>
>
>>
>> Best Regards
>> Brent
>>

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: [email-masked]
Date: Wed, 9 Jan 2013 14:57:18 +0800

Well, AS could send the request along with the auth code.

[email-masked] 写于 2013-01-09 14:47:19:

> One reason I see is, bringing the authorization code via User Agent 
> - links the user request to the authorization code. If AS directly 
> sends the code to the Resource Server the mapping between the user 
> request and the code is broken.
> 
> Thanks & regards,
> -Prabath
> 
>  
> 
> Best Regards
> Brent
>

---

From: Prabath Siriwardena <[email-masked]>
Date: Wed, 9 Jan 2013 12:29:15 +0530

> Well, AS could send the request along with the auth code.

Not quite that will be useful.. It will be a new request that when user is
directed from AS to the client. That request should identify it self.

Thanks & regards,
-Prabath

-- 
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jan 2013 23:00:03 -0800

The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. 

The redirect with code flow enables the separate contexts to be bound together. 

As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. 

Phil

Sent from my phone.

On 2013-01-08, at 22:52, cspzhouroc <[email-masked]> wrote:

> Dear Prabath:
> 
>  
> 
> But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly?
> 
>  
> 
> Best Regards
> 
> Brent
> 
>  
> 
>> One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken.
>> Thanks & regards,
>> -Prabath
>>  
>>> 
>>> Best Regards
>>> Brent
>>>

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 15:00:35 +0800

Yes, the leaking on transmission is not a security issue. However,
this code could be exposed to the resource owner or other applications
with access to the resource owner's user-agent.

[email-masked]

 14:51 (7 分钟前) 

发送至 我, cspzhouroc, oauth, oauth-bounces, Prabath 

英文

中文   
翻译邮件  

对英文停用    

I am just guessing......expecting others
answer here. 
On the other hand, auth code exposed to RO does not have
security implication, 
as far as I know: 
1. if auth code is transported
in plaintext, it should require CLient authentication to use it. 
2. if
auth code do not need Client authentication , auth code could be sent in
encryption 

Peng Zhou  写于 2013-01-09 [9] 14:42:09:  

On Wed, 9 Jan
2013 14:42:09 +0800, Peng Zhou wrote: 

> If it is the
only reason, why we send the authorization code to the
> client directly
and send another notification without the
> authorization code to the
RO. This way can mitigate the chance that

> Best Regards
> Brent
> 
> 2013/1/9 :
>> Then why not let auth code be
sent directly from AS to Client? Just want to inform RO that an auth
code has been dilivered to Client? [email-masked] [4] 写于
2013-01-09 14:27:50: 
>> 
>>> Hi Brent, Few points, why this doesn't
create any security implications.. 1. Authorization server maintains a
binding to the Client, who the token was issued to. To exchange this to
an Access token client should authenticate him self. 2. Code can only be
exchanged once for an acces token. Thanks & regards, -Prabath
>>> On
Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc wrote:
>>> Dear All: I have a
question in the section 1.3.1. Authorization Code in rfc6749 The OAuth
2.0 Authorization Framework. It tells "which in turn directs the
resource owner back to the client with the authorization code." Who can
let me know the reason why is the authorization code sent to client
through a redirection in resource owner's agent? Any security
implications? Is it possible to let the authorization server send the
authorization code to the client directly (not through resource owner's
user-agent)? Best Regards Brent
_______________________________________________ OAuth mailing list
[email-masked] [2] https://www.ietf.org/mailman/listinfo/oauth [3]
00
>> ks & Regards, Prabath Mobile : +94 71 809 6732
http://blog.facilelogin.com [5]
http://RampartFAQ.com_______________________________________________ [6]
OAuth mai
>> 
>>> /oauth">https://www.ietf.org/mailman/listinfo/oauth
>>

Links:
------
[1] mailto:[email-masked]
[2]
mailto:[email-masked]
[3]
https://www.ietf.org/mailman/listinfo/oauth
[4]
mailto:[email-masked]
[5] http://blog.facilelogin.com
[6]
http://RampartFAQ.com_______________________________________________
[7]
mailto:[email-masked]
[8] mailto:[email-masked]
[9]
http://webmail.comp.polyu.edu.hk/tel:2013-01-09

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 15:18:12 +0800

Do you mean the bounding information must be presented by the RO?
The client cannot trust the RO-client bounding information that is
received from AS? 

On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:

> The idea is to form a bridge between a user, their user-agent, and
the client application while at the same time keeping the security
credential and the client app cred separate. 
> The redirect with
code flow enables the separate contexts to be bound together. 
> As
soon as you do this in one step, then the client app needs to be able to
handle the users credentials (eg uid/pwd) directly. Remember that one of
the original reasons for the auth flow was to eliminate the password
anti-pattern. 
> On 2013-01-08,
at 22:52, cspzhouroc wrote:
>> But is it
possible to include the the mapping between the user request and the
code in the message that the AS sends to the client directly? 
Best Regards 
>>> On Wed, Jan 9, 2013 at 12:09 PM,
-Prabath 
Prabath 
>> OAuth mailing list
[email-masked] [5]
>> https://www.ietf.org/mailman/listinfo/oauth [6]

Links:
------
[1] mailto:[email-masked]
[2]
mailto:[email-masked]
[3] http://blog.facilelogin.com
[4]
http://RampartFAQ.com
[5] mailto:[email-masked]
[6]
https://www.ietf.org/mailman/listinfo/oauth
[7]
mailto:[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Jan 2013 23:31:22 -0800

The AS is independently authenticating the user and the client in separate steps.

Thus it is the AS binding that relation between user and client together ultimately in a scoped access token through a 3-leg process. 

Phil

Sent from my phone.

On 2013-01-08, at 23:18, cspzhouroc <[email-masked]> wrote:

>  
> 
> Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS?
> 
>  
>

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 16:09:20 +0800

Do you mean, in the stage that AS notify the authorization code to
the client through the RO, the AS has not authenticated the client yet.
Therefore, the AS cannot send the authorization code to the client
directly. Instead, the AS will authenticate the client when the client
send the authorization code to AS for exchanging an access token? 

On
Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote: 

> The AS is
independently authenticating the user and the client in separate steps.

> 
> Thus it is the AS binding that relation between user and client
together ultimately in a scoped access token through a 3-leg process. 

> On 2013-01-08, at 23:18,
cspzhouroc wrote:
> 
>> Do you mean the bounding information must be
presented by the RO? The client cannot trust the RO-client bounding
information that is received from AS? 
>> 
>> On Tue, 8 Jan 2013
23:00:03 -0800, Phil Hunt wrote: 
>> 
>>> The idea is to form a bridge
between a user, their user-agent, and the client application while at
the same time keeping the security credential and the client app cred
separate. 
>>> As soon as you do this in one step, then the
client app needs to be able to handle the users credentials (eg uid/pwd)
directly. Remember that one of the original reasons for the auth flow
was to eliminate the password anti-pattern. 
>>> Sent
from my phone. 
>>> 
>>> On 2013-01-08, at 22:52, cspzhouroc wrote:
>>>

>>>> Dear Prabath: 
>>>> 
>>>> But is it possible to include the the
mapping between the user request and the code in the message that the AS
sends to the client directly? 

>>>>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou
wrote:
>>>>> One reason I see is, bringing the
authorization code via User Agent - links the user request to the
authorization code. If AS directly sends the code to the Resource Server
the mapping between the user request and the code is broken. 
Thanks & regards, 
Brent
>>>>>> 
>>>>>> 2013/1/9 Prabath Siriwardena :
>>>>>> >
Prabath
Mobile : +94 71 809 6732 
[3]
>>>> OAuth mailing
list

Links:
------
[1]
mailto:[email-masked]
[8]

---

From: Phil Hunt <[email-masked]>
Date: Wed, 9 Jan 2013 00:11:20 -0800

Yes

Phil

Sent from my phone.

On 2013-01-09, at 0:09, cspzhouroc <[email-masked]> wrote:

>  
> 
> Do you mean, in the stage that AS notify the authorization code to the client through the RO, the AS has not authenticated the client yet. Therefore, the AS cannot send the authorization code to the client directly. Instead, the AS will authenticate the client when the client send the authorization code to AS for exchanging an access token?
> 
>  
> 
> On Tue, 8 Jan 2013 23:31:22 -0800, Phil Hunt wrote:
>

---

From: cspzhouroc <[email-masked]>
Date: Wed, 09 Jan 2013 16:13:40 +0800

Noted and thank you very much for your help :-) 

On Wed, 9 Jan
2013 00:11:20 -0800, Phil Hunt wrote: 

> Sent from
my phone. 
> 
> On 2013-01-09, at 0:09, cspzhouroc wrote:
> 
>> Do you
mean, in the stage that AS notify the authorization code to the client
through the RO, the AS has not authenticated the client yet. Therefore,
the AS cannot send the authorization code to the client directly.
Instead, the AS will authenticate the client when the client send the
authorization code to AS for exchanging an access token? 
>> On Tue,

>>> 
>>> Thus it is the AS binding that relation between user and
client together ultimately in a scoped access token through a 3-leg
process. 
2013-01-08, at 23:18, cspzhouroc wrote:
>>>> Do you mean the
bounding information must be presented by the RO? The client cannot
trust the RO-client bounding information that is received from AS? 

>>>> On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: 
The idea is to form a bridge between a user, their user-agent, and the
client application while at the same time keeping the security
credential and the client app cred separate. 

>>>>>> Dear
Brent 
>>>>>>>> However, I
am still not quite sure why the authorization code must be
>>>>>>>> sent
to the client through the RO's user-agent?
>>>>>>> One reason I
see is, bringing the authorization code via User Agent - links the user
request to the authorization code. If AS directly sends the code to the
Resource Server the mapping between the user request and the code is
broken. 
Best Regards
Siriwardena :
>>>>>>> Thanks &
Regards,

[4]
OAuth mailing list

Links:
------
[1]
mailto:[email-masked]

---

From: Peng Zhou <[email-masked]>
Date: Wed, 9 Jan 2013 14:39:17 +0800

Dear Prabath:

Best Regards
Brent

---

From: Peng Zhou <[email-masked]>
Date: Wed, 9 Jan 2013 14:42:09 +0800

Dear SuJing:

Best Regards
Brent

---

From: Justin Richer <[email-masked]>
Date: Wed, 9 Jan 2013 12:38:06 -0500

Brent,

If you're sending the code in the back channel directly to the Client,
as I believe you're doing from your text below, I would like you to
realize some things:

1) This is not OAuth, and is in fact antithetical to the OAuth way of
solving the connection problem.
2) You are actually lowering your overall security because the access
code is no longer bound to any particular browser session with either
the client or the AS.
3) If you're sending it directly, there is no longer any point of using
the code, since the Client is just going to turn around and send it to
the AS again to get a token. Why not just send the token? But again,
this is still not OAuth.

Think about it this way: There are three connections in the common OAuth
Authorization Code scenario, which is why it's known as a three-legged
OAuth flow in many circles. Each of these legs has unique properties, is
protected by different things, and is exposed to different pieces of
knowledge at different times.

1) Client <-> User Agent: protected by a local session of the Client's
choosing. For Web based clients this is often standard HTTP session
cookies or similar, potentially backed by a login of some type by the
user to the Client as well. This session is never exposed to the
Authorization Server.
2) Authorization Server <-> User Agent: protected by a local session of
the Authorization Server's choosing, normally through some kind of
Primary Credential (login) that the user has a the AS. Importantly,
these credentials are never exposed to the Client.
3) Client <-> Authorization Server: protected by the client credentials,
which are, importantly, not exposed to the user or user agent.

By sending the code as part of the redirect, the Client is able to prove
that the User Agent actually went to the Authorization Server (2) and
got something. The Authorization Code is then sent through the bottom
leg (3) of the channel to verify that it really did come from the
Authorization Server in the context of the user that was just there in
(1). In other words, this mechanism that you seem to be avoiding is
exactly what makes OAuth secure.

If you instead send the code through (3), then the Client as no way at
all of knowing that the user in (1) ever went to the authorization
server via (2). All the Client knows is that they sent the user
someplace and that a magic code showed up. It is very, very, very
dangerous and a very, very bad idea to assume that a code coming in the
back channel (3) has anything at all to do with any particular session (1).

This approach does *not* mitigate any real security threats, and in fact
introduces a great number of others, as described here. There are much
better ways to protect the Authorization Code, and most of the best
practices are enumerated in the security considerations document. Some
of the most common are:

1) Make Authorization Codes one-time-use (even if you try and fail, it's
thrown away)
2) Make Authorization Codes time out after a very short period (minutes
or seconds)

I hope this helps.

-- Justin

---

From: cspzhouroc <[email-masked]>
Date: Thu, 10 Jan 2013 15:18:37 +0800

Dear Justin: 

Your answer is comprehensive and very helpful :-)

Great thanks :-) 

Best Regards 

Brent 

On Wed, 9 Jan 2013 12:38:06
-0500, Justin Richer wrote: 

> Brent,
> 
> If you're sending the code
in the back channel directly to the Client,
> as I believe you're doing
from your text below, I would like you to
> 1)
This is not OAuth, and is in fact antithetical to the OAuth way of
> 3) If
you're sending it directly, there is no longer any point of using
> the
code, since the Client is just going to turn around and send it to
> the
AS again to get a token. Why not just send the token? But again,
> this
is still not OAuth.

> 1) Client User Agent: protected by a local session of the Client's
>
Authorization Server.
> 2) Authorization Server User Agent: protected by
a local session of
> 3) Client Authorization Server: protected by the client
credentials,
> If you instead send
the code through (3), then the Client as no way at
> all of knowing that
the user in (1) ever went to the authorization
> back channel (3) has anything
at all to do with any particular session (1).
> This approach does
*not* mitigate any real security threats, and in fact
> introduces a
great number of others, as described here. There are much
> better ways
to protect the Authorization Code, and most of the best
> practices are
enumerated in the security considerations document. Some
> of the most
common are:
> I hope this
helps.
Regards
>> Brent
sent directly from AS to Client?
>>> [email-masked]
[8] 写于 2013-01-09 14:27:50:
>>>> Few points,
why this doesn't create any security implications..
Authorization server maintains a binding to the Client, who the
>>>> Dear All:
I have a question in the section 1.3.1. Authorization Code in
rfc6749
>>>> It tells
"which in turn directs the resource owner back to the client
>>>> Is it
possible to let the authorization server send the authorization
code to the client directly (not through resource owner's
user-agent)?
list
>>>> [email-masked] [2]
https://www.ietf.org/mailman/listinfo/oauth [3]
Regards,
>>>> [email-masked] [6]
https://www.ietf.org/mailman/listinfo/oauth [7]
>> OAuth mailing list
[email-masked] [10]
>> https://www.ietf.org/mailman/listinfo/oauth
[11]
> OAuth
mailing list
> [email-masked] [12]
https://www.ietf.org/mailman/listinfo/oauth [13]

Links:
------
[1]
mailto:[email-masked]
[2] mailto:[email-masked]
[3]
https://www.ietf.org/mailman/listinfo/oauth
[4]
http://blog.facilelogin.com
[5]
http://RampartFAQ.com_______________________________________________
[6]
mailto:[email-masked]
[7]
https://www.ietf.org/mailman/listinfo/oauth
[8]
mailto:[email-masked]
[9] mailto:[email-masked]
[10]
mailto:[email-masked]
[11]
https://www.ietf.org/mailman/listinfo/oauth
[12]
mailto:[email-masked]
[13] https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Fri, 11 Jan 2013 17:29:14 +0800

Justin Richer <[email-masked]> 写于 2013-01-10 01:38:06:

> (1). 

How is Client assured the UA actually went to AS and got something by the 
following URL?

A：
 GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1  Host: server.example.com
C:
HTTP/1.1302Found 
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA 
&state=xyz

  In other words, this mechanism that you seem to be avoiding is
rfc6749
user-agent)?

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 11 Jan 2013 14:18:30 +0000

Because they get redirected back to the client with an Authorization Code which is then verified at the Token Endpoint without the User Agent's involvement. Sure, the User Agent could have just made something up, but then it wouldn't work at the Token Endpoint.

 -- Justin

On Jan 11, 2013, at 4:29 AM, <[email-masked]<mailto:[email-masked]>>
 wrote:

A：
 GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1  Host: server.example.com<http://server.example.com>
C:
HTTP/1.1302Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz

> > 2013/1/9  <[email-masked]<mailto:[email-masked]>>:
> >> [email-masked]<mailto:[email-masked]> 写于 2013-01-09 14:27:50:
> >>
> >>> Hi Brent,
> >>>
> >>> On Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc <[email-masked]<mailto:[email-masked]>
> >>>> wrote:
> >>> Dear All:
> >>>
> >>> [email-masked]<mailto:[email-masked]>
> >>> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>