Social Connect Reference
Normalized profile claims, the federated_identities link, redirect vs One Tap modes, and the current scope of Sign in with Google via Hawcx.
Reference for Sign in with Google brokered through Hawcx. Your app consumes the standard Hawcx ID token (OIDC reference); this page documents what is specific to the Google federation.
Normalized profile claims
Hawcx maps Google's userinfo onto its own user profile and surfaces a normalized subset in the
Hawcx ID token. The token is Hawcx-signed with iss = https://api.hawcx.com; Google's raw
claims are never forwarded.
| Hawcx claim | Source (Google) | Notes |
|---|---|---|
sub | Hawcx user_id | Stable Hawcx identifier — not Google's sub. Unchanged across sign-in methods. |
email | email | User's email. |
email_verified | email_verified | Reflects Google's verification at link time. Present when an email is on record. |
name | name | Full display name, if released by the user's consent. |
given_name, family_name | given_name, family_name | If present in Google's profile. |
picture | picture | Avatar URL, if released. |
locale | locale | BCP-47 locale, if present. |
amr | — | Standard authentication-method markers only (e.g. swk for the ZKP device-key assertion). Does not currently indicate whether the sign-in was federated — a social login and a native passwordless login produce the same amr value. |
Only what consent released
Profile fields beyond email depend on the profile scope and what the user agreed to share.
Treat name, picture, given_name, family_name, and locale as optional.
amr cannot be used to detect a federated login
If your app needs different policy for social vs. native passwordless sign-ins (e.g. stricter
step-up for social logins), do not key it off amr — it will not tell you. There is currently no
ID token claim that distinguishes the two. Track sign-in method on your own side if you need this.
The federated_identities link
Each Hawcx user carries zero or more federated-identity records describing external logins. For a Google link:
| Field | Value |
|---|---|
issuer | https://accounts.google.com |
subject | Google's stable sub for the account. |
email | Email asserted by Google at link time. |
linked_at | When the link was established. |
The (issuer, subject) pair is unique and maps to exactly one Hawcx user. See account linking.
These records are internal to Hawcx and are not emitted as ID token claims.
Sign-in modes
Redirect mode
The default. Your app runs the ordinary Authorization Code + PKCE
flow; the user picks Continue with Google on Hawcx's hosted screen, Google redirects back to
https://<your-hosted-login-host>/oidc/callback, and Hawcx completes the flow with a Hawcx code.
Nothing extra is required in your app.
To send the user straight to Google without showing the picker, pass a provider hint on the
/authorize request (and optionally login_hint=<email> to pre-fill the Google account chooser).
One Tap and token mode
Google renders its One Tap prompt directly on the hosted sign-in page and returns a credential in the browser, which Hawcx verifies server-side before issuing its own token. This requires Authorized JavaScript origins in Google Cloud.
Either way the result is identical for your app: a Hawcx-signed ID token whose sub is the Hawcx
user_id. The mode only changes how the user is prompted, never what your app verifies.
Not covered
Social Connect is authentication only. It deliberately does not:
- Grant access to Google APIs. Hawcx requests only
openid email profile; it does not request Gmail, Drive, Calendar, or other API scopes, so no Google access token is available to your app. - Store or expose Google tokens. Google's ID/access tokens are verified and discarded. There is no token vault or refresh-token storage today.
- Forward Google's ID token. Your app never receives a token with
iss: accounts.google.com— only Hawcx-issued tokens.
Google API access is future work
Requesting Google API scopes and holding a refresh token on the user's behalf (a token vault) is planned but not yet available. If you need to call Google APIs as the user today, run a separate OAuth authorization in your own app.
See also
- Overview: how brokering works.
- OIDC reference: the token, endpoints, and claim set your app consumes.
- Account linking: linking policy and the takeover guard.