Oauth2 provider not refreshing token

I’m trying to implement oauth2 for this service Authenticating with TeamGantt | TeamGantt Support (post shows all necessary endpoints and payloads)

This is my manifest:

    - key: teamgantt
      name: TeamGantt
      type: oauth2
        - email
        - openid
        - profile
      clientId: <redacted>
        type: authorization-header
        prefix: "Bearer "
        parameter: Authorization
        - teamgantt-api
          remote: teamgantt-auth
          path: /login
          remote: teamgantt-auth
          path: /oauth2/token
            accessTokenExpires: expires_in
          remote: teamgantt-auth
          path: /revoke
          remote: teamgantt-api
          path: /v1/current_user
            id: id
            displayName: email_address

The issue is that after I do login, it stays logged in for a while, and then it randomly logs me out during triggers for example, when running code like:

 const response = await api
      .requestJira(route `/rest/api/3/project/${projectIdOrKey}`);
  return response.json();

Which returns

[NEEDS_AUTHENTICATION_ERR: Authentication required] {
  serviceKey: 'atlassian-token-service-key'

My login code looks like so:

resolver.define('credentials', async ({context}) => {
  const teamgantt = api.asUser().withProvider('teamgantt', 'teamgantt-auth');
  const hasCredentials = await teamgantt.hasCredentials();
  if (!hasCredentials) {
    await teamgantt.requestCredentials();
  return await teamgantt.hasCredentials();
1 Like

It feels like some of the issue is using two remotes? teamgantt-auth and teamgantt-api (both on *.teamgantt.com). How does the token used when authenticating with teamgantt-auth get shared with teamgantt-api?

I changed the jira rest request to use asApp() and that kind of fixed the issue, but later when I use teamgantt.fetch(....) I get something like:

ERROR   15:03:23.283  2d15b33dddaf66fe  Fetch failed for remote 'teamgantt-api', provider 'teamgantt', path '/v1/projects/<id>/children?is_flat_list=true' no credentials previously requested

I tried using ‘teamgantt-api’ as the remote when requesting credentials and no luck there. I commented out the if (!hasCredentials) { guard to get it to reauth when changing those (no obvious logout methods I can find).

From an initial look here, it looks like either your initial grant flow isn’t working, or the refresh flow.

Your configuration provider definition looks correct.

api.asUser().withProvider('teamgantt', 'teamgantt-auth')

On the provider definition, the second argument (in this example teamgantt-auth) being the remote to use for your requests, so this should also match the urls you are calling.

There seems to be something missing from what you have described, so it’s hard to know why this isn’t working for you. How are you calling credentials resolver?

Can you provide some more details?

1 Like

We’re using the credentials resolver via the UI bridge.

The teamgantt-auth is defined in the top level remotes config:

  - key: teamgantt-auth
    baseUrl: https://auth.teamgantt.com

Sorry for the run around here, but the “error” you showed here in the forge tunnel log says:

serviceKey: 'atlassian-token-service-key'

Which means its not the teamgantt service that needs authentication again, but the atlassian app consent grant.

When you say “it randomly logs me out”, what consent flow is it sending you down, the atlassian one or the teamgantt one?

If its the atlassian one, it may be related to an issue we are already tracking internally.

If its the atlassian one, it may be related to an issue we are already tracking internally.

Very possible. It might be both, because we did see other errors related to auth but those didn’t seem to be atlassian based. Could the atlassian service affect the oauth providers?

Yes, the atlassian auth token is required before any other external auth tokens are processed.

So first it’s necessary to auth asApp followed by asUser?

No, that is not necessary. Whenever you use asUser we use the existing consent. It’s not necessary to do that before using your provider.

1 Like

Hi @IlyaRadchenko , can you please check again if the issue persists?
We have recently fixed an issue causing consent loops.

We are keen to see if that has solved your issue, or if its still happening.