OAuth2 Client authentication with multiple users

Question

I have built a Room Booking application in FileMaker that accesses Google Calendar via the Calendar API, authenticated with OAuth2.

Everything works well except I am unsure as to the relationship between the OAuth2 Client token flow and the individual FileMaker/GCal users who will use the system.

At the moment, I am both the owner of the project in the Google Developer Console, and the only beta tester, so naturally the system works with my calendar - I log in once, pass OAuth2 my ClientID and Secret, generate my Code, swap it for the Token and Refresh and I'm off.

However, the whole system at the moment only has one Token and Refresh, held in a single row FileMaker table, thus, when I create a second test user, things still forward to my Calendar.

This is where I am unclear. It sounds obvious, but it's hard to find a clear answer on this.

Should I have it so each user uses the same ClientID and Secret (which I keep secret from them) to generate their own unique set of Tokens?

Or is the single set enough, and I'm misunderstanding some other aspect of the system (and if so, what)?

In short: are the Tokens per Application or per User of the Application?

Answer 1

Answering my own question:

CLIENT'S (= Application) STUFF

Client ID: pertains to the Application, general to all users

Client Secret: pertains to the Application, general to all users

Redirect URI: pertains to the Application, general to all users

USER'S STUFF

Authorisation Code: specific to each user, requires the Client ID and Client Secret, and retrieved as a GET variable from the Redirect URL following user's authentication with the 3rd party service (e.g. http://YourRedirectURI.com?code=abc123)

Refresh Token: specific to each user, requires the Client ID and Authorisation Code

Access Token: specific to each user, requires the Client ID and Refresh Token, and is time limited (typically 1 hour) so a new one needs to be regenerated once it expires

NB Users should not see the Client Secret (or ideally Client ID either). They should be used in the Application's internal logic to generate calls for the users' Code/Token but not seen by them.

OAUTH2 FLOW

So, essentially the OAuth2 'Flow' is as follows:

1) Your Client ID + your Client Secret + their authentication login to the 3rd party service = that specific user's Authentication Code as GET var in Redirect URI

2) Your Client ID + your Client Secret + their Authentication Code = Refresh Token & Access Token

3) Your Client ID + your Client Secret + their Refresh Token = new Access Token