feat(auth0-api-js): Add support for Token Vault to exchange access tokens - #50
feat(auth0-api-js): Add support for Token Vault to exchange access tokens#50guabu wants to merge 2 commits into
Conversation
| constructor(options: ApiClientOptions) { | ||
| this.#options = options; | ||
|
|
||
| if (options.clientId && options.clientSecret) { |
There was a problem hiding this comment.
What about Private Key JWT?
| clientSecret: '<AUTH0_CLIENT_SECRET>', | ||
| }); | ||
|
|
||
| const tokenSet = await apiClient.getAccessTokenForConnection({ |
There was a problem hiding this comment.
Can this code snippet somehow describe the shape of the returned object?
|
|
||
| ## Get an access token for a connection | ||
|
|
||
| To get an access token for a connection using the `getAccessTokenForConnection` method, you need to instantiate the `AuthClient` with a `clientId` and `clientSecret`: |
There was a problem hiding this comment.
I'd recommend that we give more details about where the clientId and clientSecret come from... They are in fact the client credentials of the application of type resource_server associated with this API.
| ); | ||
| }); | ||
|
|
||
| test('getAccessTokenForConnection - should return a token set when the exchange is successful', async () => { |
There was a problem hiding this comment.
Would it be helpful to include a test case where the HTTP request returns an error?
The most common error case would be that the Token Vault does not have any AT for the user for the specified connection. The developer would have to handle this error case by triggering an authz flow (eventually to use connected accounts). Because there is specific error handling logic that will come from this error case, this is why I think it could be valuable to include in the covered test cases.
| connection: options.connection, | ||
| loginHint: options.loginHint, |
There was a problem hiding this comment.
Is there a practical reason that we return the input fields in the returned value? When would the caller actually use those over the inputs that it passed to the method?
Also, minor but it would be preferable that loginHint does not even get added if options.loginHint is undefined (returning a field with value undefined seems messy).
| export interface AccessTokenForConnectionOptions { | ||
| connection: string; | ||
| accessToken: string; | ||
| loginHint?: string; | ||
| } | ||
|
|
||
| export interface ConnectionTokenSet { | ||
| accessToken: string; | ||
| scope: string | undefined; | ||
| expiresAt: number; | ||
| connection: string; | ||
| loginHint?: string; | ||
| } |
There was a problem hiding this comment.
It would be useful to include some jsdoc for all these fields.
There was a problem hiding this comment.
I'm surprised that there is no test case for missing ctor option: options.domain. non-blocking but would be good to include coverage for that (probably already broken today if domain is missing and the developer tries to verify a JWT).
3 participants
Description
Adds a
getAccessTokenForConnectionmethod to exchange an access token (urn:ietf:params:oauth:token-type:access_token) for a connection's access token using theurn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-tokengrant.The API client can now optionally be instantiated by providing a client ID and secret to facilitate the exchange.
Testing
getAccessTokenForConnectionmethodChecklist