Hi,
I'm reading through draft 6 of the bearer token spec and had a
question about one of the examples. In section 2.4 there's an error
response example when an expired token is used:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
error="invalid_token"
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Sunday, July 10, 2011 2:17 AM
> Eran Hammer-Lahav schrieb:
>
> >The security of the protocol relies fully (implicit grant) or partially
> >(authorization code) on the validation of the redirection
I agree that this is something you could do, but it doesn't seem like a good
design pattern.
From: Torsten Lodderstedt
To: Eran Hammer-Lahav ; OAuth WG
Sent: Sunday, July 10, 2011 1:21 AM
Subject: Re: [OAUTH-WG] Refresh token security considerations
replaceme
Not before the submission deadline tomorrow. Probably sometime before
submissions reopen.
On Sat, Jul 9, 2011 at 9:04 AM, Eran Hammer-Lahav wrote:
> Sounds reasonable. Can you provide a schedule outline?
>
> EHL
>
>> -Original Message-
>> From: Brian Campbell [mailto:bcampb...@pingidenti
Eran Hammer-Lahav schrieb:
>The security of the protocol relies fully (implicit grant) or partially
>(authorization code) on the validation of the redirection URI. This was
>well understood by many experts but until -17, we largely ignored by
>the specification.
what does "security of the pr
Hi,
I just remembered the original aim of the text. We not just intended to list
alternative means but to get a general message across: If you cannot
authenticate a client considers this in your security design! Either (1) you
accept the fact the respective identities can be forged and handle t
replacement of the refresh token with every access token refresh is an example.
The authz server creates and returns a new refresh token value with every
access token refreshment. The old value is invalidated and must not be used any
further. Note: The authz server keeps track of all old (invali
