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
Your app consumes the Hawcx ID token, signed with iss = https://api.hawcx.com. Google's raw
token is verified and discarded server-side, and its claims are never forwarded.
The identity subset Hawcx surfaces is deliberately small:
| 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. Present when an email was verified during this sign-in. |
email_verified | email_verified | Reflects Google's verification at link time. Present when an email is on record. |
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. |
Profile fields are not surfaced to your app
name, given_name, family_name, picture, and locale are not available. The connection
requests the profile scope so Google will release them, but Hawcx does not forward them: only
email and name are read from the provider's token, and only the email reaches the ID token.
There is also no /userinfo endpoint to fetch them from.
If your app needs a display name or avatar, collect it yourself after sign-in, or source it from your own user store. Do not build against these claims expecting them to appear.
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.
Last updated on