From: Matthias A. <mat...@gm...> - 2025-01-12 13:01:13
|
Am 11.01.25 um 09:11 schrieb Andrew C Aitchison: > > New draft rfc: OAuth Profile for Open Public Clients > > https://www.ietf.org/archive/id/draft-ietf-mailmaint-oauth-public-00.html > > I am not sure how useful this will be for GMail and Microsoft, > but this may make it simpler to support OAUTH with many other email > services. > Hi Andrew, thank you for the pointer. In the end, what the Intro says is this 20-page IETF draft is pulling together existing standards, apparently there is at least one more to be written, but the bottom line is we're adding 20 more pages of text to the 423 pages of existing OAuth related ones (I've discounted three that aren't relevant to client implementors), not factoring in the W3C's Web Authentication spec, which is very long, too. RFC8252 specifically states > OAuth 2.0 for Native Apps > > Abstract > > OAuth 2.0 authorization requests from native apps should only be made > through external user-agents, primarily the user's browser. This > specification details the security and usability reasons why this is > the case and how native apps and authorization servers can implement > this best practice. So basically cementing "you must use an external browser for OAuth", or there must be an additional fetchmail-oauth2-authorizer application that doesn't store much to disk to complete that. Which is more or less another browser. Or whatever separate user-agent needs to be maintained AND SECURE (lest we endanger client systems). Uh. Also, the client app must implement considerable amounts of browsing and parsing client code, all of which fetchmail has never needed. It would specifically need a HTTPS client (meaning HTTP generator and parser, including TLS and the necessary security bits), JSON generator and parser (more or less REST API client-side support), JW* support for signatures and whatnot, all the OAuth profile knowledge, for what? Just Authentication for Mail? How can I NOT have the impression that this is all going in the wrong direction? If you see fetchmail as a set-up-and-forget piece of embedded software, that entire OAuth 2 thing is nothing but reinventing wheels so heavy that you need corporations to handle them. Looks to me that OAuth2 is wonderful because it opens so many new problems that you ever and ever need more standards to solve problems you would not have had without OAuth2 and design and implementation flaws in existing OAuth2-enabled software. Anyone who wands to help with OAuth2 nonetheless, please see <https://gitlab.com/fetchmail/fetchmail/-/blob/next/CONTRIBUTING.txt?ref_type=heads> (if that file doesn't exist in the future, and you read this from an archive, see if it became a .md or a .rst file). Best regards, Matthias |