Some endpoints require an access token to be provided. This access token consists of the generated GUID for a PocketAccount entity that has been protected using the Data Protection APIs.
It is expected that this access token would remain valid until the user revokes our access rights to their pocket account.
Keys generated by the Data Protection APIs have an expiry date, with a new key generated when the previous key has expired.
All of the endpoints that require an access token don't at any point regenerate it. As such, at some point, the access token will expire as the key used to generate it will no longer be valid (there is a grace period between when a key stops being used to protect but can still be used to unprotect).
Current impact is that a user will be forced to re-authenticate every time a key expires (every 14 days?).
We currently use the access token to evaluate what is being access and if the caller can access it. As an alternative example, the Pocket API requires a consumer key to identify what is being accessed and an access token to determine if the caller has permission to access it.
Possible options:
- Stick with the current approach, accept that users will have to re-authenticate regularly.
- Return a new access token from each API call, generated by protecting the PocketAccount ID again.
- Authenticate users via an alternative mechanism (i.e. JSON Web Tokens (JWT))
Some endpoints require an access token to be provided. This access token consists of the generated GUID for a PocketAccount entity that has been protected using the Data Protection APIs.
It is expected that this access token would remain valid until the user revokes our access rights to their pocket account.
Keys generated by the Data Protection APIs have an expiry date, with a new key generated when the previous key has expired.
All of the endpoints that require an access token don't at any point regenerate it. As such, at some point, the access token will expire as the key used to generate it will no longer be valid (there is a grace period between when a key stops being used to protect but can still be used to unprotect).
Current impact is that a user will be forced to re-authenticate every time a key expires (every 14 days?).
We currently use the access token to evaluate what is being access and if the caller can access it. As an alternative example, the Pocket API requires a consumer key to identify what is being accessed and an access token to determine if the caller has permission to access it.
Possible options: