I'm going to reiterate what has already been said.
OAuth already supports what you're trying to do. Just request a token twice,
the first time request it with a scope or scopes that allows these special
operations. The second time request it with a scope or scopes that do not.
In general I really
The Authorization header in those examples is authorizing the client.
In 4.1.3 the /token URI requires HTTP basic authorization to access.
Section 2.4 talks about this more.
-Bob
On Mon, Jul 25, 2011 at 9:27 PM, Mike Jones wrote:
> In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examp
> In short, over specification does not solve ignorance. We can and should
> highlight the possible code injection attacks on both the client and
> authorization server, as well as other security concerns around the state
> parameter. But at the end, it is up to both the client and authorization
7;s the attack vector here?
>
> EHL
>
>> -Original Message-
>> From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of
>> Bob Van Zant
>> Sent: Wednesday, July 20, 2011 9:10 AM
>> To: Breno; Eran Hammer-Lahav
>> Cc: OAuth WG
>
I think somewhere in here my original comments got lost. The spec, as
written, provides no limitations on what can go in the state variable.
If we don't define those limitations in the spec implementors are
going to define their own limitations (I'm on the verge of doing it
myself).
I propose that
On Sun, Jul 17, 2011 at 2:49 AM, Eliot Lear wrote:
> Bob,
>
> Just on this one point:
>
> On 7/15/11 5:35 PM, Bob Van Zant wrote:
>> The spec says that the value is opaque and that
>> I need to accept, store, and reply with exactly what the client sent
>> me.
&
value that has special
> meaning to the client. Putting a character limit on it will not do anything
> to prevent that.
>
> The server should reject requests with query parameters that are not properly
> percent-encoded.
>
> EHL
>
>> -Original Message-----
>> Fr
Hi everyone,
I'm in the process of implementing OAuth and I'm a little concerned
about the "state" parameter that a client can send as part of the
authorization request. The spec says that the value is opaque and that
I need to accept, store, and reply with exactly what the client sent
me. Can we i
