Entra ID SSO Vendor Security Overview for IT Teams

Audience: IT / Information Security teams evaluating P51 before granting admin consent to our multi-tenant Entra application.

This document describes what P51 does, what data we request from your Entra tenant, how we protect data in transit and at rest, and how you can audit or revoke access at any time.

---

1. What P51 Is

P51 is a background-check and consumer-reporting platform operated by PSBI. Enterprise clients’ employees use it to initiate, manage, and review background-check searches on their candidates and consumers.

• Production hostname: app.psbi.com
• Hosting: Microsoft Azure, US data residency

---

2. SSO Integration Summary

Item	Value
Protocol	OpenID Connect (OAuth 2.0)
Identity provider	Microsoft Entra ID (workforce)
App type	Multi-tenant
Application (client) ID	a8a11ab4-01c4-4255-88c0-fa58fe231234
Redirect URI	https://app.psbi.com/auth/azure/callback
Scopes requested	openid, profile, email, offline_access

What those scopes mean

Scope	What we receive
openid	User’s Microsoft object ID (unique identifier)
profile	Display name
email	Primary email address
offline_access	Refresh token (used only to maintain the session; see §4)

What we do NOT access

• No Microsoft Graph API calls. We do not read mail, calendar, files, Teams, contacts, or any other resource from the user’s account.
• No directory reads. We do not enumerate users, groups, roles, or org structure.
• No write permissions. The app registration has no Mail.Send, User.Read.All, or any admin-consented Graph permissions beyond the basic sign-in scopes above.
• No device or device-state access.

A user signing in via SSO sees the standard Microsoft consent screen showing only “Sign you in and read your profile” and “Maintain access to data you have given it access to” (the latter being offline_access).

---

3. Authentication Flow

1. User clicks Sign in with Microsoft on P51.
2. P51 redirects the browser to login.microsoftonline.com/common/oauth2/v2.0/authorize with our client ID and requested scopes.
3. User authenticates with your identity provider (MFA, Conditional Access, etc. — your policies apply, we never see credentials).
4. Microsoft redirects back to app.psbi.com/auth/azure/callback with an authorization code.
5. P51 exchanges the code for an ID token + access token over a server-to-server TLS call.
6. P51 reads the email claim and looks up a pre-existing P51 user account with that email.
7. If the account exists and is not a consumer-type account, an authenticated session is established and the user is logged in.
8. If no matching account exists, the user sees a generic “account not found” message — P51 does not auto-provision accounts.

Account provisioning

P51 accounts must be pre-provisioned by a P51 administrator before SSO will work for a user. The email address on the P51 account must match the email returned by Entra. This means a random user in your tenant (or any other tenant) who signs in will be rejected — there is no attack surface where Entra sign-in alone grants access.

---

4. Token & Session Handling

• ID token: Validated on receipt, used only to extract email/name/object-ID claims. Not persisted.
• Access token: Received but not stored long-term; P51 does not call Graph or any Microsoft API after login.
• Refresh token (from offline_access): Stored only for the duration of the user’s session. Used to refresh the ID token if the session is still active when the original token expires. Revoked on logout.
• Session cookie: Secure, HttpOnly, SameSite=Lax. Server-side session store uses TLS-only transport.
• Client secret storage: Managed via Azure platform secret storage and rotated on a scheduled cadence.

---

5. Infrastructure & Data Protection

Network & edge

• Enterprise-grade WAF in Prevention mode fronts all production traffic (OWASP-based managed rule set + bot protection).
• TLS 1.2 minimum enforced end-to-end.
• HTTPS-only; HTTP requests are redirected.

Application tier

• Application runs in a private virtual network with restricted egress.
• CSRF protection on all state-changing requests.
• Role-based access control (RBAC) enforced at the route, controller, and model layers.

Data at rest

• Document & file storage: AES-256 encryption at rest, private-only access, geo-redundant replication, HTTPS-only.
• Database: Not exposed to the public internet — access is restricted to the application’s private network. Encrypted at rest with point-in-time and geo-redundant backups.
• Cache & session store: TLS-only, private network access only.

Logging & monitoring

• Application telemetry and infrastructure logs retained for audit.
• All SSO sign-in attempts (successful and failed) are logged with email, user type, and timestamp.
• Documented incident response and disaster recovery runbooks are maintained internally.

---

6. What Your IT Team Is Being Asked to Approve

Granting admin consent to the P51 application in your Entra tenant:

• Creates an Enterprise Application entry in your tenant pointing at our publisher app registration.
• Grants the openid, profile, email, and offline_access delegated permissions for your users only.
• Does not grant any app-only/application permissions.
• Does not give us read/write access to any resource in your tenant beyond the signing-in user’s basic profile claims.

Consent is scoped to your tenant and can be revoked at any time without our involvement.

---

7. Revoking or Restricting Access

You remain in full control. Your admin can at any time:

• Revoke the app entirely: Entra admin center → Enterprise applications → find “P51 Production” → Delete or Disable user sign-ins.
• Restrict which users can sign in: Enterprise applications → P51 → Properties → set Assignment required = Yes, then assign specific users or groups.
• Apply Conditional Access policies: MFA, device compliance, named locations, risk-based sign-in policies — all your existing CA policies apply transparently to P51 sign-ins.
• Audit sign-ins: Entra admin center → Sign-in logs → filter by Application = “P51 Production”.

If you revoke or disable the app, users will immediately be unable to sign in via SSO. Their P51 accounts remain intact; they can still use username/password authentication if that’s enabled for their account type, or can be re-enabled after consent is re-granted.

---

8. Common Questions

Q: Will P51 ever call Microsoft Graph or read anything from our tenant? No. The app registration is intentionally scoped to basic sign-in only. Any future change that requested additional permissions would require you to re-consent.

Q: Can a user in our tenant who doesn’t have a P51 account get into the platform? No. The authentication only completes if a pre-existing P51 account with a matching email exists.

Q: Where is our data stored? All production data resides in Microsoft Azure data centers in the United States, with geo-redundant backup to a secondary US region. No data leaves the United States.

Q: How do we report a security concern? Email security@psbi.com.

Q: Do you have a SOC 2 / ISO 27001 / pentest report we can review? Contact your P51 account manager — we can provide current attestation documents and pentest summaries under NDA.

Q: Our policy requires that vendor apps be granted group-based assignment. Is that supported? Yes. Set Assignment required = Yes on the Enterprise Application, then assign via group. P51 itself doesn’t read groups, so this is purely an Entra-side control.

Q: Can we use our own Conditional Access policies (MFA, device compliance, etc.)? Yes. Since authentication happens entirely within your tenant before the token is issued to P51, all your CA policies apply.

---

9. Setup Steps (for your IT admin)

See the accompanying quickstart: Enabling SSO for P51 in Your Organization — one-click admin consent URL, takes <5 minutes.

After consent, provide your P51 account manager with:

• Your Entra Tenant ID
• The email domain(s) your users will sign in with
• (Optional) A list of users to pre-provision in P51