The methods on this page assume you have already created a client and are
authenticating it. If you would rather have Portal identify your end users for
you, with an email magic link, Google, or Apple, see
Client Auth. Portal creates the client as part of the sign-in,
so no server-side call is needed for a user’s first login.
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
Creating an authentication route
Initializing Portal with an authUrl
Authenticating with Client Auth
The three approaches above all assume a client already exists and your backend is authenticating it. With Client Auth, Portal identifies the end user and creates the client as part of the sign-in, so no backend call is needed at all. Instead of a credential, you pass aclientAuth configuration. Like the
authUrl approach, this never exposes a Portal credential to your DOM — the
resulting Client Session Token stays on the Portal origin — but unlike authUrl
it needs no server-side route of your own.