.
But it would be better to mention that revocation of ID token (which can be
is considered as "public" and not used to auth) definitely should cause
this error.
It would be great if we discuss this cases and improve specification.
P.S. Also it may be worse to mention that specificat
ou define, the effect of calling revocation is
> still that the token is "revoked" because the token is already not valid.
>
> So from an implementation perspective, where is the concern that developer
> will do the "wrong thing" without these more detailed error r
marc.ietf.org> wrote:
>>
>> 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
s.org/browse/KEYCLOAK-3302>
Think this is doubtful but makes sense.
To summarize: we have to create some threat model with description of
possible use cases.
On Tue, 22 May 2018 at 18:18, Sergey Ponomarev wrote:
> From OAuth perspective we can't say that the token should have som
rCD%0A4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl%0A6cQQWNiDpWOl_lxXjQEvQ'
And response contains access_token.
So my question is: maybe something similar already exists in specification?
If no, then what usually used in this case?
Regards,
Sergey Ponomarev <https:/
Hello OAuth experts,
I developed a new Grant Flow based on the Implicit Grant Flow and OIDC
and I would like to ask for it's review.
I hope it's safe, but maybe I missed something. I'll appreciate any feedback.
The Implicit grant flow was intended for authorising clients which
can't store the `cl
ding to CC authors of the spec
On Tue, 22 May 2018 at 20:29, Sergey Ponomarev wrote:
>
> 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 logou
*a token that has already been invalidated.* And I
> would interpret all other tokens as justifications for returning a 4XX
> status code.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <https://authress.io/>.
ing 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 sufficient?
>
> On 1/26/22 3:01 PM, Sergey Ponomarev wrote:
>
> Thank you, Waren,
>
>
