From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: gmail+imap+smtp (oauth2) Date: Sat, 07 May 2022 04:55:50 +1000 Message-ID: <871qx6e96v.fsf@gmail.com> References: <871qxbdulc.fsf@mat.ucm.es> <87k0b2tkg1.fsf@mat.ucm.es> <87zgjx4qhs.fsf@gmail.com> <87bkwcgmr3.fsf@mat.ucm.es> <87levfzqj2.fsf@yale.edu> <871qx7scvi.fsf@gmail.com> <87v8ujqec5.fsf@logand.com> <87ee172fjz.fsf@gmail.com> <87a6bur4z7.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16330"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.13; emacs 28.1.50 Cc: "Jorge A. Alfaro-Murillo" , emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 06 21:47:08 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nn3ut-00042C-Lj for ged-emacs-devel@m.gmane-mx.org; Fri, 06 May 2022 21:47:07 +0200 Original-Received: from localhost ([::1]:45212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nn3uq-0004Y2-RN for ged-emacs-devel@m.gmane-mx.org; Fri, 06 May 2022 15:47:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55514) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nn3tz-0003rn-Ig for emacs-devel@gnu.org; Fri, 06 May 2022 15:46:11 -0400 Original-Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]:41771) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nn3tx-0004Wx-Em for emacs-devel@gnu.org; Fri, 06 May 2022 15:46:11 -0400 Original-Received: by mail-pf1-x436.google.com with SMTP id p8so7060485pfh.8 for ; Fri, 06 May 2022 12:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=HTyGLYzw7P7RlOShHFdtqTpuj8VF9vJ58S+/dgK/jek=; b=i4gkkO/mD89u9kp6eb/0PuBxoQw9EY7q/kQawYghfDBC07J/Ou42OcH6bJh+ijlcT0 BQ/Z+Qn3w5nBjfZxGz4gliSBKMVyQm/pXwpJkdQnpbe8Zxrq+10atRHMzziDwhHnDtlR 1mFYba+2Ko1WLv/xAEcHgslISn7fj6rmezXxeTu9m4QYmzwVPMTIFGWIWvAqn7U6Dmf3 MnEJj64EIkR9QkRFf7drHyuqZfboi1veLmihKASaoVzN3S6eVLShqh1zo5T27ZAccvu5 D6/Tgu4ac6d1bV/mXngAeCUxRZV0Vn51SulzYPBd5mhc5r5dQlouejBLDwYJuxD6/Cuy MRIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=HTyGLYzw7P7RlOShHFdtqTpuj8VF9vJ58S+/dgK/jek=; b=Ips4UD4+2vhgrtFAY9KIZTXUpVw0LzZuJ54ewA/ivopcj8E23fkcRF9KX1V0TqWG1O UsfTRvto8Z/CjKY//bgcyQTr2BHpi/+tKIiHHS+nEnDlAEUyg0Lj/STqUZa31N1R04e0 GjVKx9Rxm7UcwDBzZ5/2G+aa3h/mfFM2hmtwkeWz+h2dGijT/7axs34sIrsQ2PTZgJay 7YbxX310t6S4MCzQr/mqzwlWH7spq9EC39XtUfUdJu4c/oOGtw2QPVoEK2bInkwrCPiS cPPw77CCrVA8ixAKaEuyIjSHC4QDMT6a1gFIWyreAUoV8oLQDL3/PzkeNUMpwjMPixOy TdnA== X-Gm-Message-State: AOAM532eiU3HODP3O+bTBsiB20zJLc0jtylDYjoeTZVo9ZM2AMRHvg6A m+2vX1u7S4g2EBFY4UXnWnDQUDXqiEA= X-Google-Smtp-Source: ABdhPJy6yQFFdKZ5N2cvSQ2/g1VGtYz/6VRvttOdJQo4sksK0/U+BBbdL17PsJI+Pr71DToU3WF6ng== X-Received: by 2002:a05:6a00:179f:b0:50d:e311:7d5 with SMTP id s31-20020a056a00179f00b0050de31107d5mr4820817pfg.64.1651866365682; Fri, 06 May 2022 12:46:05 -0700 (PDT) Original-Received: from dingbat (220-235-29-41.dyn.iinet.net.au. [220.235.29.41]) by smtp.gmail.com with ESMTPSA id b14-20020aa78ece000000b0050dc76281fasm3818637pfr.212.2022.05.06.12.46.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 May 2022 12:46:04 -0700 (PDT) In-reply-to: <87a6bur4z7.fsf@logand.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::436; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x436.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:289340 Archived-At: Tomas Hlavaty writes: > On Fri 06 May 2022 at 19:04, Tim Cross wrote: >>> Is the application id created by google when the oauth2 is configured by >>> a university? >> >> No. The application ID is provided by Google once the application has >> been approved by them. > > does application id mean client_id? No, At least, not necessarily and not on its own. It might form part of the client ID. Note that the oath2 spec uses the term 'client' in at least 3 different contexts. For example, the client is also the web application running on the server, not simply the end-user's client program.=20 An implementaiton can define any set of 'attributes' it wants to use as part of the authorization process. This can include an applicaiton id, a user id (for end user clients) or any other data you might want in order to assess an authorisation request (IP address, time of day, GEOIP data, whatever).=20 The client id being referred to on that site is mainly talking about a client id which can be used to idnetify specific clients. What Google wants with the application id is a way to do both analytics and a way to have a big kill switch should they find a particular class of client has soemthing suspect about it (e.g. source of DDoS attack, critical security flaw, badly behaved/written app which is adversely consuming resources etc).=20 > >> The flow sort of goes=20 >> >> 1. Register wiht google as a developer. This gives you a developer ID >> which yu can use as an application ID.=20 >> 2. Develop your application which uses oath2 to connect to google.=20 >> 3. Submit your application for approval by google. >> 4. Once approved, Google gives you an application ID which is used by >> your application. >> 5. Release your application > > understand > > and where does the university, which uses goggle mail to which a student > or teacher connects, fit in this? > how does the university configure their mail? > or has the university no say in this at all? > No, the University has considerable say. Typically, it has control over things like availability of POP3/IMAP, ability to forward mail to other servers, whether 2FA is required or not, level/type of spam filtering (warning, quarantine etc). Google (and same for MS and office365) will provide defaults and recommendations - typically very conservative (no POP/IMAP, 2FA, no app passwrods, no mail forwarding etc). Most IT departments will just following these recommendations (mainly because they want to be able to say, when things go wrong, they were following Google/MS recommendations).=20 >> Problem is, Google T&C require that the application ID is kept secret. > > it seems to be oauth2 thing, not google: > > https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/ > > The client_id is a public identifier for apps. Even though it=E2=80=99s > public, it=E2=80=99s best that it isn=E2=80=99t guessable by third par= ties, so many > implementations use something like a 32-character hex string. If the > client ID is guessable, it makes it slightly easier to craft phishing > attacks against arbitrary applications. It must also be unique > across all clients that the authorization server handles. > > For each registered application, you=E2=80=99ll need to store the publ= ic > client_id and the private client_secret. Because these are > essentially equivalent to a username and password > > oauth2 recommends keeping client_id (equivalent to username) secret > even though they call it a public identifier > Putting aside that applicaiton ID and client ID are not the same thing, not the bit=20 > It must also be unique across all clients that the authorization server h= andles. which is confusing because the term client is used to mean different things. This was exactly the sort of thing which led to the confusion regarding client id.=20 >> For open source, this is a problem because we cannot add the applicaiton >> ID and keep it secret while making the code open source.=20 > > it seems to me that oauth2 protocol is not open at all > it might be open in a sense that anybody can read the spec and implement = it > but not in a sense that anybody can read the spec, implement it and use it > (unlike other protocols like smtp or imap) I disagree. The spec is open and anyone can implmeent it in any language they want and can license it according to any license they want. Google's implementation may not be open, but someone else could just as easily write an implementation which is.=20 Note also that the actual specification is based on standard web technologies and has no requirement for Javascript - all communicaiton/negotiation can be done just using standard web form encoded data.=20 > one of the features seems to be that there is a (usually extra) party wit= h special role > having absolute authority about who to let through the gate How is that any different to any other service (including SMTP). I cannot just use any SMTP server (these days). I have to be authorised to do so and the service provider I use has full authority to reject my messages or to refuse acceptring any messages sent to my on that server.=20 Even if you had a fully open source oauth2 implementaiton, there will still be a party (resource owner) who controls access and approves/rejects requests for access.=20 The oauth2 standard is deliberately light on low level details. This does mean that different implementations may not be interoperable with each other (this is even outlined in the spec and is deliberate). It isn't trying to define a networking protocol which is interoperable with other sites like SMTP or SSH. However, that doesn't mean it isn't open. It is a spec and it is an open spec. How individual sites decide to implement that spec is up to the individual site. Where the real power of oauth2 comes into play is with the separaton of identity provider (IdP) and service provider (SP). It is this power which has enabled "login wiht XXX" functionality to develop. What would really make all of this work well is for some group (like the FSF or EFF) to setup an ethical IdP which Google (and MS, Facebook, Github, Gitlab etc) would trust to perform the client authorisation and provide the client authorization token which you then use to get the access token from Google. This woulud allow all of your sensitive identity information to be managed by someone you have trust in. Google can already do this sort of things for their enterprise customers (i.e. your home institution manages your credentials, not google). However, IAM is hard and most institutions are more than happy to allow Google (or MS Azure or ...) to do this for them.=20 Anyway, this has gotten way off topic, so I'll leave this thread alone from here. I don't think I have anything else to add.=20