Re: gmail+imap+smtp (oauth2)

[Tim Cross]

Tomas Hlavaty <tom@logand.com> writes:

> 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?

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. 

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). 

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). 
>
>> 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?
>

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). 

>> 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
>

Putting aside that applicaiton ID and client ID are not the same thing,
not the bit 

> It must also be unique across all clients that the authorization server 
> handles.

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. 

>> 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)

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. 

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. 

> 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

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. 

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. 

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. 

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.