Hi,
I might be misunderstanding the OAuth 2.0 spec (part 5.1, "expires_in"
property), but I understand that the timeout of the access token is a hard
one (amount of time between creation and expiration).
Am I right ?
Can we have a multiple use timeout ? A sliding window timeout ? Or a
combinatio
user but less convenient) and "authenticate"
> endpoint that skips authorization if the user previously authorized the app
> (more convenient but less safe).
>
>
>
>
>
>> Ciao
>> Hannes
>>
>> On Aug 3, 2012, at 12:07 AM, Jérôme LELEU wrote:
>>
Said like that, I feel totally stupid... but it's not totally without their
consent, they previously clicked on the "Authenticate at the OAuth
provider" link...
I understand that it's mandatory.
Thanks,
Jérôme
2012/8/3 Doug Tangren
>
> What are the security concerns about not having such "Al
Hi,
In the OAuth 2.0 spec, I don't see any mention of the "Allow / disallow"
screen (just after the user is logged in). However, most of the OAuth
providers I know (Facebook, Google, Twitter...) have such a "allow /
disallow" screen.
Did I miss something in the spec ?
What are the security conce
> John B.
>
> On 2012-07-04, at 1:31 PM, Torsten Lodderstedt wrote:
>
> Hi Jerome,
>
> I read the introduction of 4.1.2.1 as follows: The authorization server
> shall display an error message to the end-user. So no HTTP error code
> required.
>
> best regards,
>
Hi,
I'm trying to implement OAuth 2.0 provider support and, in particular,
right handling of errors.
Following OAuth 2.0 spec : http://tools.ietf.org/html/draft-ietf-oauth-v2-28,
I don't understand the authorization request errors : part 4.1.2.1.
If I have a valid redirection url, I understand th
