views: integrate API authentication/access control

[lnielsen]

• OAuth2 (with scopes)
• Access control

[hachreak]

@lnielsen do you think we reached the result?

[lnielsen]

• OAuth2 (with scopes)

?

[hachreak]

Should it be done by the permission factories? (see https://github.com/zenodo/zenodo/blob/master/zenodo/config.py#L392)

[nharraud]

@lnielsen I am not sure how we can have oauth2 scopes in invenio-records-rest given that it is used in different modules. Shouldn't we have different scopes for the published records and the deposits?

I planned to check the scopes directly in the permission factories as recommended by @jirikuncar (at least that's what I understood).

[lnielsen]

Yes, it should be done by permission factories, but perhaps we should provide some default scopes to rely on and which are easy to integrate?

Just thinking that right now, you can get an access token for deposit, and use that you read records, files, etc. which a user might not want a third-party to do.

For scopes I'm thinking something simple as either just records or alternatively two scopes records:read + records:write/admin/update.

[nharraud]

@lnielsen So you mean implementing optional scopes like here without creating any permission factory? If so, I like the idea. Having a records:read and records:update should be enough for most use cases and would enable to have scopes which can be reused in other modules if need be. They should just remain optional.

Note: records:update should not give access to the delete operation (which the admins can do). There should be another scope for delete, if it is needed.

@jirikuncar WDYT?

[lnielsen]

@nharraud possible the records:update/write scope could still be used to protect the delete operation, since in addition to the scope check, there's also a permission check which would fail unless you're admin…… the scopes is just to restrict what a third-party application can do with the delegated access.

[nharraud]

@lnielsen I am not sure that as an admin I would give access to the "force" delete operation to any script. Most of the scripts would just get the right to fix/migrate records.

[lnielsen]

@nharraud Yes, hence you shouldn't delegate record:update scope to the third-party app :-) However, IMHO you shouldn't even allow force delete to an admin user.