81–90 of 98 posts
Earlier quoted context omitted.
> Of course that is if the OAuth provider allows it. That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?
Google Mail's OAuth2 instructions discuss this point explicitly.
This is all good and useful, but I wish OAuth folks would fix the bugs in the spec like, e.g. "The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client." This sounds reasonable on the surface, and technically it…
These sorts of details will typically wind up in an implementation report document. It's rare that an IETF protocol specification document will attempt to pre-determine the solution to all such implementation details up front, and IMO, not good when they do.
In some contexts, it may be much better to require the application to re-obtain resource owner authorisation than to allow a replay of a refresh token. In others, it may be much better to avoid requiring resource owner authorisation. What you see as a bug, others would see as a critical feature.
This is all good and useful, but I wish OAuth folks would fix the bugs in the spec like, e.g. "The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client." This sounds reasonable on the surface, and technically it…
This is all good and useful, but I wish OAuth folks would fix the bugs in the spec like, e.g. "The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client." This sounds reasonable on the surface, and technically it…
I believe the intention here is not to verify whether it was used once as you state. And transient matters (how the client will detect if not received would be a different scope), for example, if client didn't receive (or lost), then likely here you may need restart auth cycle.
To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As…
Earlier quoted context omitted.
Google Mail's OAuth2 instructions discuss this point explicitly.
Have a link?
[0]: https://developers.google.com/identity/protocols/oauth2
Is it weird I like reading such specs? Many people find it dense, but I find it rewarding to read. What CS job would be more tuned to spending time doing this leisure?
Earlier quoted context omitted.
This is solvable by use of a web worker as a key vault: https://gitlab.com/jimdigriz/oauth2-worker
That is very cool, thanks for sharing! Edit: This seems pretty new, any timeline for a release?
Earlier quoted context omitted.
There's a spec for dynamic registration of clients for Oauth2/OIDC if I recall correctly. There's a reason that you have to register, and it's because you're potentially obtaining information about users, and they need a way to be able to block specific (potentially malicious) clients using their IDP.
When I was looking up the OAUTHBEARER draft, there's a (OPTIONAL) field in the error response to point to the openid-configuration for dynamic registration. At the time I was implementing things for Thunderbird, no one was using this yet, and I would be surprised if this has actually been implemented by any major provider in any sort of usable way for clients.