When creating GitLab "Applications" for the purpose of 3rd party integrations, you also create access-tokens to enable said communication between GitLab and 3rd party software.
As of GitLab 15, access-tokens (and refresh-tokens) expire after 2hrs. GitLab seems to explain in their docs that it is now expected that access-tokens (or refresh-tokens) be refreshed every 2hrs in order to keep them alive.
This means that a lot of old 3rd party integrations are now breaking in my dev environments. Is it expected that the 3rd party software now implement some cron-job or other type of scheduled job to be able to keep tokens alive?
Or should 3rd party integrations request "Personal Access Tokens" that can have an extended lifetime, and avoid having to implement "refresh logic" for all potential customers that they support?
[should apps] implement some cron-job or other type of scheduled job to be able to keep tokens alive?
No. While this can work, you should only create live tokens when you actually need to use them. That's why you have a refresh token -- to get new tokens after the access token expires. There's no reason to constantly keep access tokens "fresh" and available if you can generate new tokens on-demand.
Your best bet is to build this "refresh logic" into your integrated applications. The fact that tokens do not expire by default in GitLab <15 is really more of a security bug/oversight than a feature.
Note also that refresh tokens remain valid, even after the access token expires. Per the docs (emphasis added):
To retrieve a new
access_token, use therefresh_tokenparameter. Refresh tokens may be used even after theaccess_tokenitself expires. This request:
- Invalidates the existing
access_tokenandrefresh_token.- Sends new tokens in the response.
Or should 3rd party integrations request "Personal Access Tokens"
This is an option, but it's a completely different approach compared to using an OAuth application and, depending on what your integration needs, might require each individual user of your app to create a token and provide it 'manually'. The available scopes for PATs are also different than the scopes available for OAuth apps. So, it's possible, but for a number of reasons, less desirable than an OAuth application.
This might be acceptable for integrations that don't necessarily need to access resources on behalf of users, but can get away with a ~single token (say, a Group Token or a PAT belonging to a member of the customer's top-level GitLab group) or solutions where you want to enroll project-by-project using a project token or similar.
However, if your integration needs to access resources on behalf of users or only needs access appropriate for a limited scope that is not available for access tokens (like email or profile scope), this probably wouldn't be a good approach. You also can't make "trusted" integrations this way.