As I see from a security perspective it should be fine if the API may say
that the token was already revoked. The token is by itself a secret which
should be hard to guess. Otherwise an attacker may just call userinfo
endpoint.
So leaking information if the token was used or existing is not so
dang
As Justin pointed out earlier in the thread, if the value `token` is
clearly not a valid token, then returning an invalid_request response is
fine. The key is if the value provided for the token parameter is a
token, then the API MUST NOT leak whether the token was valid or not.
Is this not su
Thank you, Waren,
Sorry that was misleading, I meant literally the 'null' as a string which
may be because of a bug in the client.
That was an example taken from Thomas Broyer letter:
> For months, my AS received requests with token=Array, and now receives
requests with token=null. Those are clea
According to RFC7009, I don't see anywhere which says you have to return a
200 for token=null. I interpret it as you return a 200, if the token passed
would never have been accepted as a valid token. *Null* isn't an invalid
token, it is an invalid value for the *token* parameter which is required.
Hi and sorry for raising the four years old topic.
As a recup I reported a SECURITY VULNERABILITY on OAuth 2
specification level. It's minor (I hope) but still seen in the real
world AS implementation.
In short, to logout a user the revocation endpoint is called with the
user's token. And by a the
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
>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
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
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
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
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
I’m with George here: revocation is almost a best-effort request from the
client’s perspective. It sends a message to the server saying “hey I’m done
with this token, you can throw it out too”. If the server does revoke the
token, the client throws it out. If the server doesn’t revoke the token?
I'm not understanding how these different cases matter to the client? I
doubt that the running code will be able to dynamically handle the
error. So it seems this information is only relevant to the developers
and not relevant from an end user and the client perspective.
Also, for the 5 states
Hi,
I developing an implementation of back channel token revocation endpoint.
And I think we should reconsider and probably change the specification to
improve error handling.
Here we see several situations of error state:
1. token wasn't sent in request.
2. token is invalid by format i.e. not JW
14 matches
Mail list logo
