Single sign-on (OAuth2)
Configure OAuth2 single sign-on providers to let customers log in with Facebook, Google, Microsoft, or custom identity providers.
Single sign-on (SSO) lets your storefront customers log in using their existing accounts from external identity providers instead of creating a separate PrintNow username and password. The integration uses the OAuth 2.0 protocol and supports three built-in providers (Facebook, Google, Microsoft) as well as fully custom OAuth2/OpenID Connect providers.
SSO is configured per-storefront. When a provider is active, a login button for that provider appears on the storefront login page beneath the standard username/password form. On first login, PrintNow automatically creates a customer account linked to the external identity. On subsequent logins, the customer is matched by email address and authenticated without a password.
View Providers
- From your Unified Admin, go to Partner Integration > Single sign-on (OAuth2).
- The provider list shows all configured OAuth2 providers for the current storefront in an AG Grid table.
- Use the Action menu on any row to Toggle State (activate/deactivate) or Delete a provider.
Provider List Columns
| Column | Description |
|---|---|
| Client Id | The OAuth2 client ID registered with the identity provider. |
| Client Secret | The OAuth2 client secret for authenticating with the provider. |
| Name | Display name of the provider (e.g., "Facebook", "Google", "Microsoft", or a custom name). This name appears on the storefront login button. |
| Offline | Whether offline access (refresh tokens) is enabled for this provider. |
| Scope | OAuth2 scopes requested during authorization (e.g., openid email profile). |
| Token Endpoint | The provider's token exchange URL. Pre-filled for built-in providers. |
| Authorization Endpoint | The provider's authorization URL where users are redirected to log in. Pre-filled for built-in providers. |
| UserInfoEmailKey | JSON key in the user info response that contains the user's email address. |
| UserInfoFirstNameKey | JSON key in the user info response that contains the user's first name. |
| UserInfoIdKey | JSON key in the user info response that contains the user's unique ID. |
| Active | Checkbox indicating whether this provider is currently enabled on the storefront login page. |
| Action | Menu with Toggle State and Delete options. |
Add a Built-in Provider
Built-in providers (Facebook, Google, Microsoft) come with pre-configured OAuth2 endpoints, scopes, and user info key mappings. You only need to supply the Client ID and Client Secret from the provider's developer console.
- Click Add Provider in the header.
- From the Providers dropdown, select Facebook, Google, or Microsoft.
- Enter the Client Id and Client Secret obtained from the provider's developer portal.
- Click Save.
Each built-in provider can only be added once per storefront. Attempting to add a duplicate throws an error.
Where to Get Credentials
| Provider | Developer Portal | Notes |
|---|---|---|
| Meta for Developers (developers.facebook.com) | Create an app, enable Facebook Login, and copy the App ID and App Secret. Set the OAuth redirect URI to https://<your-storefront-domain>/oauth2. | |
| Google Cloud Console (console.cloud.google.com) | Create OAuth 2.0 credentials under APIs & Services. Set the authorized redirect URI to https://<your-storefront-domain>/oauth2. | |
| Microsoft | Microsoft Entra (portal.azure.com) | Register an application under App registrations. Set the redirect URI to https://<your-storefront-domain>/oauth2. |
Add a Custom Provider
Custom providers allow you to configure any OAuth2-compliant identity provider with full control over endpoints and user info field mappings.
- Click Add Provider in the header.
- From the Providers dropdown, select Custom.
- Fill in the configuration fields (see table below).
- Click Save.
Custom Provider Fields
The custom provider form is split into two columns:
| Field | Description |
|---|---|
| Name | Display name for this provider. Appears on the storefront login button (e.g., "Okta", "Auth0", "Azure AD"). |
| Client Id | The OAuth2 client ID registered with your identity provider. Required. |
| Client Secret | The OAuth2 client secret for server-side token exchange. |
| Scope | Space-separated list of OAuth2 scopes to request (e.g., openid email profile). Determines what user data is returned. |
| Authorization Endpoint | URL where the user is redirected to authenticate (e.g., https://provider.com/authorize). |
| Token Endpoint | URL where PrintNow exchanges the authorization code for an access token (e.g., https://provider.com/token). |
| User Information Endpoint | URL where PrintNow fetches user profile data using the access token (e.g., https://provider.com/userinfo). |
| User Info Email Key | JSON key in the user info response that contains the email address (e.g., email). Used to match or create the PrintNow customer account. |
| User Info Id Key | JSON key in the user info response that contains the user's unique identifier (e.g., sub or id). |
| User Info FirstName Key | JSON key in the user info response for the first name (e.g., given_name). |
| User Info LastName Key | JSON key in the user info response for the last name (e.g., family_name). |
| Offline | When enabled, requests offline access from the provider so that a refresh token is returned. This allows PrintNow to refresh expired access tokens automatically without requiring the user to re-authenticate. |
Manage Providers
Toggle Active State
From the provider list, click the Action menu on any row and select Toggle State. Active providers show a login button on the storefront. Deactivated providers remain configured but are hidden from the login page.
Delete a Provider
From the provider list, click the Action menu and select Delete. A confirmation dialog appears. Deleted providers are soft-deleted (marked as deleted in the database) and no longer appear in the list. Existing customer accounts linked to the deleted provider are not affected — those customers can still log in with their PrintNow username and password.
Authentication Flow
When a customer clicks an SSO login button on the storefront, the following happens:
- The customer is redirected to the provider's authorization endpoint with the configured scopes and a callback URL of
/oauth2on your storefront domain. - After the customer authenticates with the provider, they are redirected back to your storefront with an authorization code.
- PrintNow exchanges the code for an access token at the provider's token endpoint.
- PrintNow calls the user information endpoint to retrieve the customer's email, name, and ID.
- PrintNow looks up an existing customer account by email address. If no match is found, a new customer account is created automatically with a randomly generated password.
- The customer is logged in via a forms authentication cookie and redirected to their original destination.
If offline access is enabled and the provider returns a refresh token, PrintNow stores the OAuth2 credentials and automatically refreshes expired tokens on subsequent requests.
Associations
Print Store
| Area | Effect |
|---|---|
| Login Page | Active SSO providers appear as login buttons below the standard username/password form with the text "Or login with..." followed by a button for each provider. The button label matches the provider's Name field. |
| Customer Accounts | When a customer logs in via SSO for the first time, a new customer account is automatically created with their email, first name, and last name from the provider. The account is assigned a random 60-character password since authentication is handled by the external provider. |
| OAuth2 Callback | The storefront registers an /oauth2 route that handles the OAuth2 authorization code callback. All configured providers share this single callback URL. |
| Token Storage | OAuth2 access tokens, refresh tokens, and expiry data are stored in the ObjectMeta table under the Customer.ExternalLoginAccount scope. This allows automatic token refresh for providers that support offline access. |
| Organizations | If the storefront uses organizations, SSO user lookup is scoped to the customer's organization. New SSO users are mapped to the appropriate organization and user group based on their referral domain. |