Re: gmail+imap+smtp (oauth2)

[Tomas Hlavaty <tom@logand.com>]

On Fri 06 May 2022 at 19:04, Tim Cross <theophilusx@gmail.com> 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?

> The flow sort of goes 
>
> 1. Register wiht google as a developer. This gives you a developer ID
> which yu can use as an application ID. 
> 2. Develop your application which uses oath2 to connect to google. 
> 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?

> 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’s
   public, it’s best that it isn’t guessable by third parties, 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’ll need to store the public
   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

> For open source, this is a problem because we cannot add the applicaiton
> ID and keep it secret while making the code open source. 

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)
one of the features seems to be that there is a (usually extra) party with special role
having absolute authority about who to let through the gate