Authenticating with a Client API Key
This approach requires the least setup, but is also the least secure as it exposes your Client API Key to your DOM. For this reason, we recommend that this method only be used during local development. The only thing required for this is to create a client like normal via the Portal REST API and use theclientApiKey for the apiKey option when initializing Portal.
Authenticating with a Web OTP
This approach is a bit more secure as it instead exposes a OTP to your DOM and once this is used, it’s invalidated on Portal’s end, which makes it unusable for authentication in the future. The steps required to accomplish this are:- Make a
GETrequest tohttps://api.portalhq.io/api/v1/custodians/clients/${clientId}/web-otpusing yourCUSTODIAN_API_KEYas aBearertoken. - Initialize
Portalwith the delivered OTP as theauthTokeninitialization option.
Fetching a Web OTP
Initializing Portal
Authenticating with an authUrl
This approach is by far the most secure as it never exposes any Portal credentials to your DOM. This works by adding a route to your application that fetches an OTP and redirects to Portal’s server for validation. The URL to your authentication route is then provided as theauthUrl option when initializing Portal.
The steps required to accomplish this are:
- Create a route on your server that gets a new Web OTP and redirects to
https://web.portalhq.io/clients/token/validate?otp=YOUR-WEB-OTP - Enable CORS access to
https://web.portalhq.ioon your new route - Initialize
Portalwith yourauthUrl