# Legisym Token Generation & onboarding usage ## Introduction At the moment there is only one hardcoded issuer on Caro, because we set the URL & token via environment variables. The UI also has the link to Legisym in its code. While preparing the backend to accept multiple UI redirect links & tokens from issuers, I examined the architecture that Legisym uses to link an incoming user to an onboarding on our site. ## Flow Onboarding flow: 1. UI POSTs onboarding 2. UI GETs partner token 2.1. Backend calls Legisym to generate token (includes lifetime) 4. UI builds link to Legisym 4.1. includes the onboarding ID 5. Legisym calls CARO API to get details about onboarding 5.1. probably shows data related to onboarding? ## Problem Legisym trusts the onboarding ID in step 4. to correlate the Legisym user token to an onboarding on CARO's site. The user could exchange the ID in the process to one of another tenant and there is no barrier blocking the user accessing the Legisym form of another tenant's onboarding. ## Proposal I think we should first lose the call number 2. from the UI flow. The backend should generate a token if it's needed after creating the onboarding. If the life time is a problem, we could persist it alongside the token and automatically handle refresh in the backend. The backend then always puts out the token with the onboarding. Also the token should be generated with a scope in mind. It would be nice if we could call Legisym for generating the token with an Onboarding ID to directly limit it to exactly that onboarding. Regarding the dynamic redirect URL that the initial ticket is about, I would like to add it to the onboarding entity at runtime. It is persisted with the service provider, but when a user gets it in the UI, they should see it in the response body. This way the UI can directly link to Legisym without requesting any other resource and/or matching the selected service provider in the UI.