I hope people don't feel I'm derailing the conversation. All I'm saying is that using the EXTERNAL authentication described as in the original proposal has interesting properties, but it might be overloading the meaning of EXTERNAL when in fact there is a different, standardized mechanism with similar properties.
On Fri, Feb 15, 2019 at 01:35:20AM +0500, Ненахов Андрей wrote: > чт, 14 февр. 2019 г. в 21:39, Ivan Vučica <[email protected]>: > > > Technically, OAuth2 is not really tied to HTTP, if this is what you > > mean. For all that it matters, you could use XMPP as the transport to > > obtain the access+refresh token (or just a 'permanent' access token). > > > > Well, https://tools.ietf.org/html/rfc6749 states: > > > This specification is designed for use with HTTP ([RFC2616 > > <https://tools.ietf.org/html/rfc2616>]). The > > use of OAuth over any protocol other than HTTP is out of scope. > > > > In my book this pretty much means that if you use other protocol (XMPP, > Pigeon post or whatever), it's no longer OAuth. That's why our developed > protocol resembles this very sensible and importatn protocol, but is not > identical to it and does not use it for the reasons I've stated in previous > email. Honestly, I didn't check enough to find that assertion, but I think it's moot given existence of RFC 7628 which also expands use of OAuth tokens to SASL: > This document defines how an application client uses credentials > obtained via OAuth over the Simple Authentication and Security Layer > (SASL) to access a protected resource at a resource server. Thereby, > it enables schemes defined within the OAuth framework for non-HTTP- > based application protocols. (Especially the last sentence.) When I said it doesn't depend on HTTP, I mainly meant 'tokens can still be provisioned in an arbitrary way'. You could have the user perform an XMPP login into one service, obtain the access+refresh token, and then use it on another. In theory. Discovery of how to perform the authentication+authorization dance would be an important part of the hypothetical XEP describing how to use RFC 7628. I'd say there's nothing wrong with using HTTP, but the same or even a separate XEP can specify use of something else? > > The only way you could address your problem is to issue the access > > credentials via a desktop, which indeed is addressed in the original > > proposal. However, I see this problem as totally orthogonal to 'how do > > we get rid of stored unscoped master passwords on every device a user > > uses'. > > > > Well, we're probably talking about different things. Only in the part that I was responding to -- there was an assumption I was trying to solve the problem of 'assuring the user that [the client developer is] not trying to steal user's password'. That was not what I was suggesting how to solve. So I replied that if you do want to solve it, you really need to take the authorization flow fully off device (which things like game console/smart TV YouTube are doing by having the user enter a 4 digit code on desktop and then log in, which then somehow magically transports the tokens back into the console app). > The practical problem > we're addressing is a capablity to reconnect without a password, and to > give account owner means to revoke this capability. We are concerned about > this because every single XMPP client out there has to keep user's XMPP id > and passwords to be able to reconnect, and this is bad - someone who gets > access to device can potentially obtain said password and impersonate a > user. And this is beyond very bad. I do think revocable, scoped tokens are one of the strengths of OAuth2's design. See GitHub, BitBucket, Google, ... I'm merely suggesting that it seems like basing your approach around a SASL mechanism named after it would be beneficial for interop? :-) Using OAuth2 token was already done before, too: https://developers.google.com/talk/jep_extensions/oauth https://blog.process-one.net/details_on_msns_xmpp_server/ https://github.com/robbiehanson/XMPPFramework/wiki/FacebookChatHowTo Because access tokens are intended to be valid for only a short time (let's say an hour), revoking refresh tokens is usually sufficient. In XMPP's case, there might need to be a nudge to kick out existing sessions and connections, forcing reauthentication -- that is, the authn/authz backend needs to propagate revocation mainly due to long-livedness of the XMPP connections -- but otherwise, even if there is no revocation propagation to drop existing connections, doesn't this have majority of the properties you're describing in your approach? Interestingly, I'm right now using a custom SASL method for libsasl2 (XOAUTH2) to send this email from Mutt. So my email client is unaware of anything OAuth2-related, yet it doesn't have access to the password, either. It doesn't even see the refresh token; I have a small tool that swaps the Google refresh token for an access token, which Mutt then uses as a password provided to the SASL mechanism plugin. So if I used an XMPP client with libsasl2, and the server offered the relevant mechanism, I could log into the server without the client being aware anything new is happening. The XEP merely needs to address discovery of login UI endpoint, token swap endpoint, and such user interaction concerns. Login itself, less so. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
