# RFC: Page to call Work Entity Service API
One of the finals parts of the fulfilment flow from 99designs to Vistaprint is taking the user from a given design file into Vistaprint's "PDC" page, which gives them final product configuration options for their given printing project. This is the first time a user will transition from a 99designs page to a Vistaprint page, and requires the usage of a number of Vistaprint APIs to prepare the design before they are redirected.

The tricky part of this is that the Vistaprint APIs that are called are not 'machine to machine', like the rest of the APIs during the flow (99designs containers calling Vistaprint APIs with the one authnetication token). Instead, the APIs need to be called on behalf of the user, which means that a Vistaprint auth token needs to be procured for the user for 99designs to then call the APIs on their behalf.

This will explore some possible ways that we are able to get this token for the user, before calling the APIs for them.

## Option 1 (Recommended): Build the 'page' on 99designs side

The flow would look something like this:

Client->Projects: /projects?docRefUrl=something, redirect to accounts
Client->Accounts: `SSO` entry page, target=/projects?docRefUrl=something
Client->Auth0: Auth redirect
Auth0->Auth0: Show login page if not logged in
Client->Accounts: `SSO redirect page`
Accounts->Auth0: Exchange code for access token
Client->Projects: Use target + access token, `/projects?docRefUrl=something&token=token
Projects->Print: `CreateWorkItem` RPC
Print->Vistaprint: Create `work` API call
Client->Vistaprint: Redirect user to PDC

Pros:
- API calls can happen from 99designs- Twirp is available to `print` service
- Uses `accounts` to orchestrate token exchange- endpoints pretty much exist already
- Target functionality already exists to push user around to different places
- Keeps everything on 99designs side for as long as possible

Cons/Questions:
- User needs to be logged in before going to PDC (OAuth flow does not support anonymous users). Too much friction in the flow?
- Are we allowed to put the user into this flow?

https://github.com/99designs/projects/pull/4491
https://github.com/99designs/accounts/compare/redirect-token-spike?expand=1

## Option 2: Always use an anonymous token to do the PDC call
Use the [Anonymous Authentication Service](https://developer.cimpress.io/apis/auth/anonymous-authentication-service#/token/createIdentityAndToken) to create a new anonymous token each time, to use in the WES call.

Cons
- Doesn't work, once the user is redirected to VP the PDC/design are only valid for that particular Anonymous token. I thought maybe they could have the concept of 'claiming' an anonymous created work item, but they don't.

## Option 3: Host the page on VP
This would host the page on VP (possibly through Vistapro pipeline)

Pros
- Would handle both anonymous/logged in users by default, since we could look directly at the user's token and user that for API calls

Cons
- Maybe complicate calling into the `print` RPC service
- Couldn't make use of `projects` codebase for validation
- Deployments would be more complicated, as changes to the flow would require changes in potentially `projects`, `print` and in the VP route

## Option 4 (future): Consolidated auth, use token directly
The end game for this approach should be to utilise consolidated auth, which should mean we always have access to a valid token to call Vistaprint APIs from 99designs, as the user itself will be an Auth0 user. This will take out any of the redirect flows presented above, and APIs could be called directly for a token that is already available on 99designs.