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
GET
request tohttps://api.portalhq.io/api/v1/custodians/clients/${clientId}/web-otp
using yourCUSTODIAN_API_KEY
as aBearer
token. - Initialize
Portal
with the delivered OTP as theauthToken
initialization 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.io
on your new route - Initialize
Portal
with yourauthUrl