Member management

You need app-registration rights, such as Application Developer. A Cloud Application Administrator or Application Administrator can grant tenant-wide consent for this setup. See Microsoft's registration and consent roles.

1. In Entra ID → App registrations, create a single-tenant app. Under Authentication, add a Web platform with Platform's Redirect URL.
2. Under Certificates & secrets, create a client secret. Copy its Value, and use the Application (client) ID as the client ID.
3. Under API permissions → Microsoft Graph → Delegated permissions, allow openid, email, and profile. Grant admin consent if your tenant's consent policy requires it.
4. If Enterprise apps → Properties → Assignment required? is enabled, assign the intended users or groups and grant tenant-wide admin consent. See the assignment rules.

https://login.microsoftonline.com/TENANT_ID/v2.0

Replace TENANT_ID with your Directory (tenant) ID, a UUID. The shared common and organizations issuers do not identify your tenant.

Entra can supply xms_edov=true instead of email_verified=true. Platform accepts this only for the exact tenant issuer above and still requires email. Merge these optional claims into the app's Manifest, preserving its other settings:

{
  "optionalClaims": {
    "idToken": [
      { "name": "email", "essential": false },
      { "name": "xms_edov", "essential": false }
    ]
  }
}

Test with an account whose email domain is verified in the tenant. Requesting the claim does not make it true for every account; upn and preferred_username do not replace email. See Microsoft's claim requirements and scope reference.

Use an App Admin for app setup. Changing a custom authorization server requires API Access Management Admin or equivalent permissions. See Okta's role permissions.

1. In Applications → Create App Integration, choose OIDC – OpenID Connect → Web Application. Enable Authorization Code and add Platform's Sign-in redirect URI.
2. Set Client authentication to Client secret with client_secret_basic; PKCE can be required. Assign the app to the intended users or groups. Keep Login initiated by set to App Only.

https://YOUR_OKTA_DOMAIN

The ID token must contain the verified primary email and boolean email_verified=true. Authorization Code flows can omit scope-dependent claims from the ID token even when they appear in UserInfo.

If your org server omits them, use a custom authorization server with an issuer ending in /oauth2/SERVER_ID. Allow this app and the three sign-in scopes in its access policy. Update the existing default ID-token claims email and email_verified to always include, preserving their system values. With Okta's default-claim resource, set always_include_in_token = truefor both. These are reserved names; do not create replacement custom claims. Test the actual Authorization Code result. Production custom servers require API Access Management.

Follow Okta's web-app setup and ID-token claim configuration.

Use the project's OAuth Config Editor role (roles/oauthconfig.editor) or equivalent permissions.

1. Use a Google Cloud project owned by your Workspace organization. In Google Auth Platform, configure Branding and set Audience → Internal to limit sign-in to that organization.
2. Under Clients, create a Web application OAuth client. Add Platform's Redirect URL under Authorized redirect URIs, then copy the client ID and client secret.

https://accounts.google.com

Allow the basic openid email profile scopes. The ID token supplies sub, email, and email_verified; no service account or domain-wide delegation is needed. If Workspace API controls block the app, an admin with Service Settings privilege must allow its OAuth client ID for the intended users.

Platform checks the verified email domain, not Google's hd claim. Keep the Internal audience restriction when organization membership is required. See Google's OIDC reference and audience and consent setup.