Single Sign-On Under Your Own Name

Google and Microsoft sign-in work out of the box through an application Pental registers, and the only place that shows is the consent screen: the first time somebody signs in, the browser asks whether they want to give Pental access to their account. Everything else they touch is yours. Registering your own application closes that last gap, and it is part of white-labelling the portal.

You need BOTH the client ID and the client secret for a provider before anything changes. With one of the two stored, that provider carries on using the shared application, because half a credential produces an error on the provider's own screen with nothing to say why.

The redirect URI, first

Both providers refuse to sign anybody in unless the address they send the browser back to is registered against the application in advance, character for character. Yours is your portal address with /api/sso on the end:

• Your own domain, if you have connected one: https://portal.yourfirm.com/api/sso
• Otherwise your Pental subdomain: https://yourfirm.pental.io/api/sso

The settings screen prints the exact value for your portal, with a Copy button, so copy it from there rather than typing it. No trailing slash, https rather than http, and the hostname people actually sign in on. If you connect a custom domain later, add the new URI to the application before you switch, and keep the old one until nobody is using it.

Google

Google’s console now gathers the consent screen and its clients under Google Auth Platform, in pages called Branding, Audience, Data Access and Clients. APIs and Services, OAuth consent screen, which the portal’s own steps name, leads to the same place.

1. In the Google Cloud console, pick or create a project for this, and open Google Auth Platform.
2. Under Branding, set the application name and the user support email. The application name is the point: it is the words your people read on the consent screen, so make it your firm, not "Portal". Add your logo and home page if you want the screen fully branded; Google may review the application before it shows a logo to accounts outside your own organisation, and sign-in works meanwhile.
3. Under Audience, choose External. While its publishing status reads Testing, only the test users listed there can sign in, so publish it.
4. Under Data Access, add the scopes openid, email and profile. Sign-in asks for nothing else.
5. Under Clients, create a client of the Web application type. Under Authorised redirect URIs, add the address above; nothing goes in Authorised JavaScript origins.
6. Create it, then copy the client ID and the client secret.

Microsoft

• In the Microsoft Entra admin centre, open App registrations, then New registration.
• Name it after your firm, for the same reason.
• Under Supported account types, choose who may sign in. This has to agree with the Microsoft directory field in Pental: single tenant goes with your directory ID, any organisational directory goes with organizations, and any Microsoft account goes with common.
• Set the Redirect URI to Web, and paste the address above.
• Register it, then copy the Application (client) ID from Overview and, if you chose single tenant, the Directory (tenant) ID beside it.
• Open Certificates and secrets, New client secret, and copy the VALUE, not the Secret ID. Microsoft shows it once and never again.
• Under API permissions the defaults are enough: openid, email and profile. No admin consent is required for those.

A Microsoft client secret expires, and the maximum is two years. Put the expiry date in a calendar the day you create it. When it lapses, sign-in through your application stops; paste a new secret into Pental and it works again straight away.

Putting them into Pental

1. In your portal, open Settings, then the Login Page tab.
2. Expand Use your own Google / Microsoft app (white-label sign-on).
3. Paste the client ID and the client secret for each provider you registered, and set Microsoft directory: common for any Microsoft account, organizations for work accounts, or your directory ID for your organisation only. A single-tenant app refuses common.
4. Press Save login page.

The secret is encrypted inside your own database on the way in and is never sent back to a browser, so the field is blank on every later visit and the label says Stored. Typing a new one replaces it; leaving it blank leaves the stored one alone.

Where the sign-in code is exchanged

An administrator’s Login Page tab says, under Where sign-in is made, whether your own database makes sign-in for this portal. Once it does, it begins and finishes single sign-on too: with your own application, your database exchanges the code Google or Microsoft sends back, using the secret it keeps, so Pental’s servers take no part in the exchange and never read the secret. That happens by itself once your database sends the portal’s email (a connected mailbox, or a Pental gateway) and can reach Google and Microsoft. Until then, Pental’s server reads the secret at the moment somebody signs in, through a signed call your database records.

Check it, and going back

• Sign out, open your portal, and use the Google or Microsoft button. The consent screen should now name your firm.
• If it still names Pental, the client ID is empty or the save did not land. If the provider refuses with a redirect mismatch, the URI registered against the application is not exactly the one your portal prints.
• If Microsoft refuses with an application-not-found error, the Microsoft directory field and the Supported account types do not agree.

Clearing the client ID puts that provider back on the shared application, and sign-in keeps working throughout. The same application can also reach SharePoint or Google Drive, if you keep copies of reports there.