Setup user authentication with any identity provider

Authress Authentication works as identity aggregation. This means that it provides a central point to combine any number of user identity management or federated login providers in a single place. For example Google and Office 365 login. Providing a solution that works with just one is easy, but to support both and then normalize the data, this becomes more complex.

Authress normalizes these providing standard OIDC complaint JWTs which includes secure session management.

In this guide we’ll use Google login as an example of how to connect. Setting up authentication requires the following parts:

  1. Authress-Google OAuth configuration
  2. New application setup
  3. User login flow
  4. Service API token verification
  5. [Going further] Custom Domain

Google OAuth configuration

Select the first login provider you wish to integrate. For this example we’ll pick Google.

Google login buttons

  1. Enable the Google preconfigured connection.
  2. Follow Google’s instructions to set up an OAuth 2.0 app credentials, and then when creating your OAuth 2.0 credentials, specify
    • Authorized Javascript origins: https://custom.domain (Replacing the custom.domain with the domain specified above.)
    • Authorized redirect URIs: https://custom.domain/login (Replacing the custom.domain with the domain specified above.) Google Admin create connection
  3. Obtain the OAuth Client ID and Client Secret from your Google Developer dashboard.
  4. Paste the Client ID and Client Secret from Google to your Authress Connection Google Admin oauth connection credentials
  5. [Optional] Update the OAuth consent screen with your application’s information.

Google Admin oauth consent screen

For all other connections

Some connections already have pre-configured Authress defaults, such as Google’s. In all other cases, additional information might be required, such as:

  1. Specifying Authorization URL (example:
  2. Specifying the token URL (example:

New application setup

A provider connection creates the user’s identity, and applications consume them. Connecting applications allows them to consume credentials. To prevent compromised user credentials, only listed applications are allowed to connect to your providers.

Specify an internal name for the application and the allowed domains for the application to run. Only these fully-qualified domain names will be allowed to use your connections. More specifically these applications must have top level domains that match your custom domain that you created.

Authress create web application

User login flow

With the configuration in place, your website app can configure the login experience you want.

  • Install the site Authress Login SDK javascript package for managing user credentials: npm install authress-login.

Users should be able to select which connection they want. Since we only have google, offer them a branded Google Login Button. When users click the button activate the authenticate() method in the library:

Service API token verification

The site is now successfully sending tokens from your website to your service API, but the service needs to verify those tokens are valid. The easiest way to do this is send the tokens to the Authress Authorization apis, as Authress will automatically verify the tokens or return back a 401. However, it can be more secure (and faster) to verify the tokens on the service side, on every API request verify the user token before continuing.

To do this use the TokenVerifier in the authress-sdk service package: npm install authress-sdk

[Going Further] Custom Domain

  • Prerequisite: You need DNS provider access

After getting your first application working, it would be time to publish it with your domain. For security reasons every Authress tenant operates on a unique subdomain of your product’s domain. While localhost testing works out of the box, to deploy it to the domain, a custom subdomain needs to be configured. You will need to have access to your domain’s CNAME records to add the relevant ones necessary for Authress. These are required to alias to our authentication server and create a certificate restricted to the relevant domain. Once you have access to your DNS provider’s zone, follow the instructions for setting up a custom domain.

Non standard OAuth configuration

Some OAuth providers do not use JWTs or don’t follow RFC standards for access tokens exchange. For examples and errors on how to set these up, check out OAuth setup guide - part 2.

Didn't find what you were looking for?

Or send us an email at