Re: gmail+imap+smtp (oauth2)

[Tim Cross]

Tomas Hlavaty <tom@logand.com> writes:

> On Tue 10 May 2022 at 17:51, Tim Cross <theophilusx@gmail.com> wrote:
>> Tomas Hlavaty <tom@logand.com> 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.