I think one important point Sergey raised was that the response to the client
from submitting the wrong token is the same 200 response as submitting a valid
token, and that hugely increases the chance that the developer of the client
app might submit the wrong token and never realise. Making it
Hi,
Joseph, thank you for your details, that's exactly what I meant.
On my full time job I developing a platform where we have a lot of
connected small sites. And most of them are just another brands for
different markets of the same company. So their developers mostly just copy
source code from o
Comments on OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-06
The text is scaring ! It is quite hard to understand under which
/context(s) /and conditions OAuth 2.0 could be safely used.
1° A "Privacy considerations" section should be added. It is important
to plac
In that specific case, the token_type_hint value is invalid and can be rejected
as an invalid_request.
— Justin
> On May 22, 2018, at 5:27 AM, Joseph Heenan wrote:
>
>
> I think one important point Sergey raised was that the response to the client
> from submitting the wrong token is the sa
IFF the server processes it!
RFC 7009 says “An authorization server MAY ignore this parameter,
particularly if it is able to detect the token type automatically.” which
BTW is exactly my case.
For months, my AS received requests with token=Array, and now receives
requests with token=null. Those ar
>From OAuth perspective we can't say that the token should have some
structure: they can be any random value in case of reference (opaque)
tokens. But the Google's OAuth Server responds in this case with 400 error
"invalid_token".
The same can be used for JWTs with invalid sign or issuer.
So it wou
What is also should be discussed and specified is revoking of expired
token. For example in Keycloak you can invalidate a session by expired
token:
> It should be possible to logout a session with a token that is expired.
> This is to make sure that a user can invalidate a session if there's a
> s
Hi Denis,
> On 22 May 2018, at 14:05, Denis wrote:
> In particular, the text states:
>
>"Clients shall use PKCE [RFC7636] in order to (with the help of the
> authorization server) detect and prevent attempts
> to inject (replay) authorization codes into the authorization
> res
