d for unprotected operations) we prevent it from being intercepted. This
> design intentionally mimics the way secure and non-secure http cookies work.
>
>
> ** **
>
> Oauth today basically requires https for all bearer token implementations.
> I would like to see this
Is separating this out into 2 different tokens, really the best way to solve
your use case?
It sounds to me that you simply want to track/log the two types of accesses
differently, which can be done entirely outside of the oauth2 process.
Just bucket your operations into two piles internally and t
ent secret, in contrast, can be
> used to authenticate it.
>
> regards,
> Torsten.
>
> Am 14.09.2011 19:12, schrieb Dave Rochwerger:
>
> Thanks for the follow up, Torsten.
>>
>> Whilst I have your attention - any thoughts on my second question,
>> about
provide for private clients in the
authorization code flow?
Thanks,
Dave
On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt
wrote:
>
> Hi Dave,
>
>
> On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:
>
>> 1. "The user does not have to be present."
>
nt wrote:
> See below...
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
> On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote:
>
> Hi Phil,
>
> >> The client is then forced to periodically reauthentic
long
> lived access tokens too, and just use the refresh tokens when you want to do
> something new with the access tokens.
>
> ** **
>
> -bill
>
> ** **
> --
>
> *From:* Dave Rochwerger
> *To:* oauth@ietf.org
> *Cc:* Quizlet Dev Team
> *Sent:
long
> lived access tokens too, and just use the refresh tokens when you want to do
> something new with the access tokens.
>
> ** **
>
> -bill
>
> ** **
> --
>
> *From:* Dave Rochwerger
> *To:* oauth@ietf.org
> *Cc:* Quizlet Dev Team
> *Sent:* Wedne
You can have long
> lived access tokens too, and just use the refresh tokens when you want to do
> something new with the access tokens.
>
> -bill
>
> --
> *From:* Dave Rochwerger
> *To:* oauth@ietf.org
> *Cc:* Quizlet Dev Team
> *Sent:*
Hi all,
I have been implementing OAuth2 based on the various drafts for our new API.
Initially, I implemented everything as per the spec, but due to our
particular scenario and restrictions we have in place, there are some
fundamental questions that I am unable to defend.
I am hoping this group c