[WPB-28050] New oauth scopes for meetings for calendar integration. (part 1)

[fisx]

https://wearezeta.atlassian.net/browse/WPB-28050

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[MarianKijewski]

@fisx To be exact, you can remove "google" from the title and changelog, as it's for both gmail and outlook.

[fisx]

There is a complication: we have a "write implies read" rule in libzauth, so we can't grant oauth access to PUT, but deny it on GET for the same path.

Solutions:

1. make libzauth scope rules more flexible (expensive)
2. grant read access to writers under GET /meetings/:dom/:id.

I have implemented 2 in 75b59f6.

[MarianKijewski]

There is a complication: we have a "write implies read" rule in libzauth, so we can't grant oauth access to PUT, but deny it on GET for the same path.

Solutions:

1. make libzauth scope rules more flexible (expensive)
2. grant read access to writers under GET /meetings/:dom/:id.

I have implemented 2 in 75b59f6.

Or 3rd option. Change backend API so GET /meetings/:dom/:id and POST /meetings don't exist on same OAuth scope plane, by for example:
a) changing the creation path to /meetings/create. Not really RESTful naming, but some way out.
b) changing scope naming convention to include path parameters.

[fisx]

We decided to do it right.

1. only add the write:meetings scope on /meetings and leave out the ones that are impacted by the limitation of libzauth
2. make libzauth scope rules more flexible so that this fixed for future use cases and we can grant scopes/permissions more granularly aligned with the principle of least privilege