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: Tue, 10 May 2022 22:39:16 +1000 Message-ID: <87tu9xcya8.fsf@gmail.com> References: <87k0atmx1w.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31345"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.19; emacs 29.0.50 Cc: rms@gnu.org, fitzsim@fitzsim.org, jostein@kjonigsen.net, emacs-devel@gnu.org To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 10 15:30:32 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 1noPwd-0007sW-8J for ged-emacs-devel@m.gmane-mx.org; Tue, 10 May 2022 15:30:31 +0200 Original-Received: from localhost ([::1]:53096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1noPwc-00014g-4x for ged-emacs-devel@m.gmane-mx.org; Tue, 10 May 2022 09:30:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1noPuh-00079l-O4 for emacs-devel@gnu.org; Tue, 10 May 2022 09:28:31 -0400 Original-Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]:42787) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1noPua-0006di-Rh; Tue, 10 May 2022 09:28:27 -0400 Original-Received: by mail-pf1-x436.google.com with SMTP id x23so14938040pff.9; Tue, 10 May 2022 06:28:22 -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; bh=xNBOVzoTgDCcgufbmfpXdHmqYnXAjlSj7Mc3wuLIQjg=; b=iw8YcfNCf492Cz/nycyobmWbRrRwMvLs725b64GcQ8nTJ09+eMHDcdUy/HH524p+q5 Jnb3QEjDSnCoeH4p6JBnWYCokxReKZR4e5dLmA7/OYGDl4zGxhmjVzoe2tfcmZf8V/Pd Ue9OKkWIqrYCt6ciyjUp/hGwyJZ5tOu9XmWa263P2D+zqAJiD0t2uEQvtttJqYukcAe5 OVkR56wAIdsQLB6Cmqp0yABul63lhozDAEycYUR8qQdrBgrYJFDiS+5p6/PefCbCiPtM zEAA+jGv15Et1M2Jj6fOrd7TIXt7gopsx2pJ985uzgLTEgWbn3e6Rg9PbrCh2gIBndEI zRsw== 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; bh=xNBOVzoTgDCcgufbmfpXdHmqYnXAjlSj7Mc3wuLIQjg=; b=aimZ6I5Aoalo1q1CQNkEbkkkCv1YR5R4F94BJIT6mxV63vxTn4R0pvGqSjteKRnGFj ccth8qvy2gKFjWVls6pq8Fc8MTKwYZQcrfm4iOw2Mq9/VJ9Vkn2t4eL1iNUkV7qNhDGT A6t6F5UV68IBYGONH2upzJIZ2s4mTsGSnT06w9kwqJi2upt9kygOuHB4EB3834pTp98L e/iTrE7czTz/Q4Bbw/QEa2RztIiJrq3fDnq2DRSKj/ZkN1ZNnN6dA4xODZTjN8lqOJHZ qHMcAKziyoQaQS29IdYn0WfW3eqHXGBpbkn0YvMf3BM35WNoJ54AQVIbK7V2stMVAli8 YIwA== X-Gm-Message-State: AOAM531skBtH6c4XV5XtNtDXuHK6/DGmwatcPXG72KPADuzKSmOI6GM0 v4o/Pno6kbqng+ybFDpziaTWEWOmgoA= X-Google-Smtp-Source: ABdhPJzxz91afumturA616fakbcMlmyKyTm60w4n0vc+hsUqBcy22DTuJHYTEkG1XODl1DHR4GGPTQ== X-Received: by 2002:a05:6a00:24d2:b0:510:9f7a:3eec with SMTP id d18-20020a056a0024d200b005109f7a3eecmr11561130pfv.57.1652189301205; Tue, 10 May 2022 06:28:21 -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 n10-20020a170902e54a00b0015e8d4eb256sm2074306plf.160.2022.05.10.06.28.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 06:28:20 -0700 (PDT) In-reply-to: <87k0atmx1w.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:289586 Archived-At: Tomas Hlavaty writes: > On Tue 10 May 2022 at 17:51, Tim Cross wrote: >> Tomas Hlavaty writes: >>> When a school/university demands gmail account >>> and google locks me out of my gmail account, >>> what happens? >> >> When a school/university makes a decision to use Google as their email >> provider, it isn't 'normal' google - it is your school/university's >> email, essentially hosted by google. As such, your institution controls >> access, not google. Google just provides the service to your >> school/university. Often, the setup involves integration with your >> school/university IAM system i.e. your 'identity' (your username) is >> managed by the school/university. This integration makes it easier for >> existing school/university workflows to continue i.e. onboarding of new >> students/staff, removal of accounts when students/staff leave etc. It >> also makes integration with other services, such as on-line LMS (Moodle, >> Blackboard etc) easier as there is just one 'meta directory' of all >> accounts. This is where oauth2 shows its strengths. Your institituion >> essentially becomes a identity provider which Google trusts. When you >> request authorisation credentials, they are provided by your >> institutions IAM system. Your client then submits those authorisation >> credentials to get an access token from Google which you then submit to >> the Google service you want to access (i.e. email). > > thank you for the explanation > > who is in charge of giving out oauth2 client_id? > does it mean that the university gives out client_id? > > is it still google who gives out application id > (the google specific and required additional parameter for the oauth2 client?) > It really depends on exactly how the integration has been configured. However, the typical model is that your institution would provide the client authorisation credentials i.e. your institution will say if you are or are not a valid user and what resources your permitted to access. This will typically happen with Google acting as a sort of proxy. The process will go something like 1. You connect to a login service. This could be a service provided by Google or one provided by your institution. If it is one provided by Google, you will login with something like username@your.institution.edu. Google will then pass the information you provide in the login (minimum of username and password, but possibly (likely) a 2FA token as well) to your institutions IAM system. Your institution will verify the user, password and any additional information and if all passes, returns an authorisation token to google, who in turn return it to you. Your client then presents the autorisation token to Google who then gives you an access token (possibly including a refresh token). Your client then presents the access token to get access to whatever service you wanted (i.e. email) and your client does what it needs to do. In a sense, this is very similar to those web sites which say "Login wiht Facebook. Github, Google, whatever. The site your trying to access really just proxies the initial verification process, passing the details you enter on to the respective ID provider who does the actual validation. So, your institutions IAM system is responsible for the initial assessment to determine if the client request is permitted. Your institution could require any number of IDs, really up to them. In this scenario, it is unlikely they will do application vetting and provide application IDs, so they would not be required. They could however, require a different ID - for example, student number. This is the key point about oauth2 - it isn't prescriptive about exactly what is involved in the client approval cycle. The oauth2 specification just mapps out the authorisation workflow, not the speicifics of what information is passed in the requests/responses - for oaht2, these are just payloads. In the case of Google, they want to be able to control 'classes' of applications. For them, they want protection against a vulnerable application being used to compromise large numbers of thier users. For example, a new email client in the play store which has been approved and given an application ID. Later, a major security hole is found in that applicaiton. If it is severe enough, google might suspend the application ID associated with that application to prevent further exploits until the application is patched. Note that what I've outlined is at a very high level. It is based on a number of projects I have worked on integrating systems with various services and identity management systems. As usual, the devil is in the details. Where oauth2 helps is that it standardises the workflow and communication processes. It avoids going into details about the lower level specifics (crypto algorithms, credential attributes, etc). It focuses on defining the parties involved and the way data flows between those parties and to some extent, the http headers and/or web form encoding. All the non-free javascript involved with Google has nothing to do with oauth2 - that is all just UI stuff google uses on it web login page i.e. is just the Google specific web page interface. I suspect (but have not verified) that Google probably provides an API interface where the data could be sent directly, bypassing the Google UI page, simply by generating the correctly formatted form data and posting it to the correct URL (which would require an applicaiton ID). My guess is this is how other applications (like thunderbird) work. I have heard of a number of people who have registered themselves as developers with Google so that they can get a developer ID, which you can use as an application ID, in order to craft their own process. Only problem with this is that it requires registering with Google and requires greater technical understanding than most average users have/want.