OAuth2 Token refresh implemented

[mesemus]

Important: we are aiming to release this at the same time as #360. When we merge, we need to align the DB migrations, but still keep them as 2 separate migrations so that one can be run manually. This migration does not need to be run manually in any scenario.

Description

Closes #68.

Added fields on RemoteToken model:

• refresh_token
• expires_at

Added properties on RemoteToken:

• is_expired

New methods on RemoteToken:

• refresh_access_token

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings.
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Frontend

• I've followed the CSS/JS and React guidelines.
• I've followed the web accessibility guidelines.
• I've followed the user interface guidelines.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[palkerecsenyi]

Thank you so much for creating this PR @mesemus, it looks like quite a bit of work and will improve security a lot while also adding support for more modern and spec-compliant OAuth servers. I'm aware it's been over a year, I'm coming back to this as I need refresh token support for the upcoming GitLab integration (inveniosoftware/invenio-github#190) and this PR is 99% of the way there. I apologise for the large number of suggestions, these are mostly just nitpicks :)

I'm also very happy to fix them myself in a new PR if you're busy. Thanks!

[palkerecsenyi]

Just so I understand how to use this, is the intention that users of this module manually check is_expired and then call refresh_access_token if needed? I personally agree with this approach (automating this would make everything a bit more confusing and blackbox-y), just want to check this is what you meant.

[ntarocco]

You marked this comment as resolved, but I had the same question :)
What is the answer? ☺️

[palkerecsenyi]

Ah yes sorry, should have explained here! Yes the intention is that users manually check this, which lets us avoid a potentially confusing blackbox design where the token refresh happens internally.

For example, here is how it's used in Invenio-VCS:

@cached_property
def remote_token(self):
  token = RemoteToken.get(self.user_id, self.factory.remote.consumer_key)
  
  if token is None:
      return None
  
  if token.is_expired:
      token.refresh_access_token()
  
  return token

[slint]

LGTU (with @palkerecsenyi), some extra warnings/guidance for the db.session.commit() and we need to update copyright headers.

[kpsherva]

does this mean we plan to support old style tokens indefinitely or we plan to phase them out at some point?

[palkerecsenyi]

We phase them out immediately. When the user logs in with OAuth and returns to the authorized endpoint, we check if we need extra sign up info (which is usually the case on Zenodo). If so, we need to store their credentials in the session until they complete their account, which is when we do the token exchange with the identity provider. The only case where the old token would be returned from the session is if a user was in the middle of completing the extra info form when we did the deploy, and here we are ensuring that this edge case is handled gracefully.