Add service token exchange method

[jonbarrow]

Resolves #XXX

Changes:

As per PretendoNetwork/account#189 (comment), the account server no longer has a way to validate service tokens. This is intended, as service tokens are special and need to be handled special

These changes adds a new ExchangeServiceTokenForUserData method to the Account service. I am only focused on our needs right now, which is why the API service has not been touched (as that service is supposed to be a replacement for the "public" http-based API used by the website, the Account service is for our internal needs)

Notably it separates token and user info into their own messages, so that services can be told of when the token was issued so they can handle expiry as they see fit

Marked as a draft to allow for discussion about the needs of the returned data. Right now the same user data as returned by ExchangeTokenForUserData is used, but we can change this

The client_id field is the same ID used to get a service token from NNAS. This is used so that NNAS can lookup that services encryption key. For example, Juxt would send 87cd32617f1985439ea608c2746e4610 (the Olive client ID)

CC @ashquarky. Once this is merged, and the account server updated, Juxt should never have to worry about decrypting tokens again

• I have read and agreed to the Code of Conduct.
• I have read and complied with the contributing guidelines.
• What I'm implementing was an approved issue.
• I have tested all of my changes.

[github-actions]

The latest Buf updates on your PR. Results from workflow Validate Pull Request / check_buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	❌ failed (1)	Jul 2, 2025, 10:22 PM

[ashquarky]

(You have to bump the version in package.json lest Actions be sad)

So the idea is that we would move to ExchangeTokenForUserData for OAuth, and ExchangeServiceTokenForUserData for service tokens? It's important to me that they both return the exact same datatype (which this does).

Looks like that method somehow escaped having linked_devices added to it, so making that tweak would be good.
Since we're updating fields, there's also some on Api.GetUserData that aren't replicated here: updated_date, timezone, connections, marketing_flag. I think the internal API should have all the data on it so we don't need to hit multiple API endpoints if I want to find the timezone.
("all the data" except for stuff that shouldn't leave the account server at all, of course, so no device certs and the like)

TokenInfo looks good. I noticed there's a title_id field in the current tokens, is that worth doing anything with?

[jonbarrow]

(You have to bump the version in package.json lest Actions be sad)

I know, I intentionally left it not updated since there's also an existing PR and we don't know the final version number right now. Same reason why I haven't pushed any generated code, because we aren't sure of the final protobufs

So the idea is that we would move to ExchangeTokenForUserData for OAuth, and ExchangeServiceTokenForUserData for service tokens? It's important to me that they both return the exact same datatype (which this does).

Correct 👍 I figured we'd want the same data, so I just reused the return type, but if we want to edit it here we can (though I don't see why we would)

Looks like that method somehow escaped having linked_devices added to it, so making that tweak would be good.
Since we're updating fields, there's also some on Api.GetUserData that aren't replicated here: updated_date, timezone, connections, marketing_flag. I think the internal API should have all the data on it so we don't need to hit multiple API endpoints if I want to find the timezone.
("all the data" except for stuff that shouldn't leave the account server at all, of course, so no device certs and the like)

Got it, nice catch 👍

I noticed there's a title_id field in the current tokens, is that worth doing anything with?

Probably not? Ideally service should know its own title ID(s). It can be added though (I could just yeet back the entire token struct tbh)

[ashquarky]

Same reason why I haven't pushed any generated code, because we aren't sure of the final protobufs

Oh, I believe the Actions do that for you anyway.

Yeah, no, I want the same user document for both OAuth and service token flows, it makes the TypeScript much easier to wrangle. Currently we're using GetUserDataResponse for that.

Probably not? Ideally service should know its own title ID(s). It can be added though (I could just yeet back the entire token struct tbh)

Maybe there's some validation reason? Though yeah it feels like a stretch

[jonbarrow]

That should cover it all I think? Went ahead and bumped the version and marked as ready for review now

[ashquarky]

Sorry I forgor about this. API LGTM