hackerman
hackerman
Thank you for the idea - the concept looks really interesting. I'm not sure if it addresses the issue we have here though. The proposed standard prevents resending the same...
> Google expects the old refresh token to keep working until they have sent a request using the new token. That only works if your infrastructure uses the introspection endpoint...
True, we don't keep that around. I think we should add that field to the table! Does the table have any foreign keys on e.g. login or consent requests?
Ok, I don't remember if the constraint is cascade delete or cascade set null. If it is the latter, this table would be safe for purging old records
The problem with the proposed query is that it would delete login session, which deletes authentication session, which deletes (I think) consent session, which deletes access tokens. So while the...
While it looks like a reasonable approach, there are so many different grant extensions to the existing OAuth2 protocol in draft (or self-defined by e.g. Google) that we simply lack...
You can use client_credentials if you want to. The proposed draft above is something completely different.
We currently lack use cases / popular demand and resources to tackle this, but do welcome contributions. As a word of caution, this will be a lot of work to...
Sounds good! I'll reopen that - for clarification, this will be about implementing https://tools.ietf.org/html/rfc8693 right?