Trade in shared secret for an OAuth-grade refresh/access token?

[michielbdejong]

We could benefit from OAuth best practices if we frame OCM as a pro-active flavour of OAuth.
The resource owner pro-actively gives the client access and sends them a shared secret via OCM.
After that, the current practice is that the client would then use this secret as-is to access the resource API (WebDAV or otherwise).
It might be better if we use the OAuth framework to make sure this client secret is not included in each network request.

[michielbdejong]

See also #80

[michielbdejong]

So we would remove

OCM-API/spec.yaml

Lines 465 to 469 in b45c7a0

	sharedSecret:
	type: string
	description: |
	An optional secret to be used to access the resource,
	such as a bearer token.

And then instead the flows would be something like this:

• invite-first, and public-link and share-with flows happen the same way as usual, with the difference that sharedSecret is left out
• the receiving server requests access to the resource, acting as an OAuth client at this point
• the sending server recognises the domain name of the receiving server and gives out access
• The Client Credentials Grant seems appropriate here, but there might be other options - to be discussed
• the receiving server can now access the resource

[michielbdejong]

I'm not sure if we should push for this without a proactive ask for it from vendors. Will close it until someone asks for this option to be added.

[butonic]

This is a blocker for oCIS. I'll try to clarify our requirements next week.