Skip to content

Conversation

@nshirley
Copy link
Contributor

Because:

  • Some partners that use the existing attached_clients enpoint don't need as much data as it currently provides
  • And the existing endpoint can be slow depending on other data being fetched

This Commit:

  • Adds a new attached_oauth_clients endpoint
  • Adds support for a new query to handle the unique clientId constraint at the db level
  • Adds tests

Closes: FXA-12616

Checklist

Put an x in the boxes that apply

  • My commit is GPG signed.
  • If applicable, I have modified or added tests which pass locally.
  • I have added necessary documentation (if appropriate).
  • I have verified that my changes render correctly in RTL (if appropriate).

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Other information (Optional)

This adds a new endpoint at account/attached_oauth_clients. No parameters are needed since we use the uid off of the sessiontoken.

It will return a unique list of authorized oauth clients, or empty if there are none. If there are multiple refreshTokens for the same clientId, then we prioritize the most recent lastUsedAt. Responses are simple and look like this:

[ 
  { 
    clientId: "3c49430b43dfba77", 
    lastAccessTime: 1769311751000 
  }, 
  { /** more unique clients...*/ }
]

// or, for no authorized clients
[]

@nshirley nshirley marked this pull request as ready for review January 26, 2026 20:00
@nshirley nshirley requested a review from a team as a code owner January 26, 2026 20:00
* Gets a unique list of refresh tokens for a given user.
* Groups by clientId, returning only the most recently used token for each client.
*/
const QUERY_LIST_UNIQUE_REFRESH_TOKENS_BY_UID =
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went this route to offload the compute of uniqueness and limiting to only the most recent lastUsedAt to mysql. It's something that mysql should be good at handling - though I'm open to suggestions if it's better to hoist this into the service layer so we're not making a new query where we don't need. If we go that route I can re-use the existing call, and then filter and constrain in the service

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer this approach. Let the database do its thing.

* @param {*} getTokens
* @returns
*/
async _processRefreshTokens(uid, getTokens) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting all and unique refreshTokens should be processed the same (compared against refreshTokens in redis).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logic of these new functions should be identical to what list was doing before, but with a new listUnique I didn't want to functions that are just copy/paste of eachother. This just splits it out to be a bit easier to read and used by the old list and new listUnique

return tokens;
}

async getRefreshTokensByUid(uid) {
Copy link
Contributor

@dschom dschom Jan 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that you added doc to function above. Do this here too? And on the next method.

Because:
 - Some partners that use the existing attached_clients enpoint don't
   need as much data as it currently provides
 - And the existing endpoint can be slow depending on other data being
   fetched

This Commit:
 - Adds a new attached_oauth_clients endpoint
 - Adds support for a new query to handle the unique clientId constraint
   at the db level
 - Adds tests

Closes: FXA-12616
@nshirley nshirley merged commit eea716a into main Jan 28, 2026
21 checks passed
@nshirley nshirley deleted the FXA-12616 branch January 28, 2026 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants