OAuth2 provider action "retrieveProfile" with Tempo OAuth

The Tempo API does not provide a self/me endpoint what is the desired way to fill in the “retrieveProfile” action within the oauth2 provider in a forge app to access the Tempo API?

1 Like

Is there any user-related API that returns some name and id field for the consented user?

1 Like

Unfortunately not, there is no API to retrive the Atlassian User with name/id field. The advise to use the https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-myself/ (“GET /rest/api/3/myself”) API from Jira.
But how can I use this within the oauth2 provider “retrieveProfile” request?

I see where the Tempo docs say to use the myself API you referenced: REST API documentation :thinking:

Two things worth trying:

  1. Using the myself API for the retrieveProfile
retrieveProfile:
  remote: atlassian-myself
  path: /rest/api/3/mypreferences
  resolvers:
    id: id
    displayName: username
remotes:
  - key: tempo-oauth
     baseUrl: https://api.tempo.io/
  - key: atlassian-myself
     baseUrl: https://api.atlassian.net/

I’d be super surprised if this worked because it would mean that the Tempo token can be used against the Jira API. But this snippet from the Tempo docs kind of makes it sound like that is the case:

Identifying users

The Tempo REST API uses the Atlassian accountId to identify users. The accountId is an opaque identifier that uniquely identifies the user.

The accountId of the current user can found using the Jira Myself API.

Information about a user, given the accountId, can be retrieved using the Jira User API.

  1. Use the response from a GET to Tempo’s /accounts. You get back an id and a name from the accounts endpoint:
"id": 7,
"name": "Cloudbay: Development",

I wonder if you can use those to hydrate the user profile feeds. Note: I don’t have a great understanding of how the profile data is used throughout the Forge app so it might be a very bad practice to use names/ids that could be “assigned” to multiple users of your app. I’ll see if @MichaelCooper can provide some more thoughts on this.

Thanks for the advices.

  1. This is what I have already tried 2 weeks ago, but without success. Anyway I will try again, but I think that the JIRA API does not accept the Tempo token (which you already mentioned)

  2. Tempo’s /accounts API is totally different from a Jira/Atlassian User, these accounts are somewhat else for managing time tracking to e.g. a customer account.

1 Like

The profile retriever is currently used for 2 things:

  1. To allow the user to differentiate between multiple accounts on the Connected Apps screen.
  2. To differentiate between a new account and an existing account.

When finishing the OAuth flow, if the id field from the profile retriever is the same as previously (for this user), it will replace the existing token.
However, if it’s different, it will add a second token.

It would be fine if it was always the same value, you just would never be able to link multiple accounts.
However, if it was different every time, the user would end up with lots of tokens, and result in some weird behaviour.

I hope this helps

1 Like

What I was predicting: when using the /read/api/3/mypreferences then I will get a 401:

could not retrieve profile information: {"message":"Client must be authenticated to access this resource.","status-code":401}

Ok I tried again my workaround which works 2 weeks before but was broken after a Forge update:
I write my own profile retriever with an API to Tempo which works without any problems, but then it was broken until the recent Forge update from yesterday :smiley:

I used this in my manifest:

function:
    - key: main
      handler: index.run
      providers:
        auth:
          - tempotime
    - key: tempo-profile
      handler: auth.retriever

...

retrieveProfile:
  remote: tempo-apis
  path: /core/3/work-attributes/
  function: tempo-profile

...

remotes:
  - key: tempo-apis
    baseUrl: https://api.tempo.io

And in my auth.ts file in the retriver function I return a static object:

...
return new AuthProfile({
  id: '12345',
  displayName: 'Some Name',
});
...

@bentley and @MichaelCooper thanks for your help.

4 Likes