uBix Core 0.45 — Continue with Facebook

Facebook Is Not Google

uBix Core’s sign-in seam, IdentityProviderServiceInterface, has had a Google implementation since 0.14. Google speaks OpenID Connect: the sign-in hands back a signed ID token, and the framework verifies the signature against Google’s published keys. No call home, no trust in anything the browser carried.

Facebook doesn’t work that way. Its web login returns an access token, not an ID token, and there’s nothing local to verify. So FacebookIdentityProviderService, new in 0.45, asks Meta instead, and it is strict about how:

• Whose token is this? Every token goes to Graph’s debug_token endpoint, and the answer must name your app id. A token minted for some other app, which a user could have obtained there legitimately, is refused. Without this check, any Facebook app’s token could sign someone in to yours.
• appsecret_proof on every call, so a leaked token alone can’t be replayed against the Graph API on your app’s behalf.
• Tokens in the Authorization header, never the URL, where they would end up in proxy logs.
• PKCE is sent as with Google. Whether Meta enforces it is not something I’ve been able to confirm. The tests check that it’s sent, nothing more, and the docs say so.

From the outside it’s the same seam. A host that already does Continue with Google adds Facebook with one container binding and a switch.

Deleting What Facebook Gave You

Meta won’t approve an app that offers Facebook Login unless it has a data-deletion callback. When someone removes your app in their Facebook settings, Meta POSTs a signed_request that names the user. FacebookSignedRequestParserService verifies it: HMAC-SHA256 over the payload with your app secret, compared in constant time, and anything that isn’t HMAC-SHA256 refused outright. What to delete stays the host’s decision. The framework only makes sure the request really came from Meta.

What the Host Still Owns

Two decisions stayed in Sowing.me, where they belong:

• Facebook never says an email address is verified, and sometimes sends none at all. Matching an unverified address to an existing account would let a stranger claim it. So Sowing.me proves the address itself with a one-time code before matching it. It already had the code machinery from its passwordless sign-in.
• The deletion receipt stores no identifier. Meta wants a confirmation code and a page where the person can check their request. Sowing.me keeps a random code, the provider, a count and a time. Keeping the Facebook user id would mean keeping the very thing the person asked it to delete.

Honestly

It’s merged, tagged and wired up, but it hasn’t signed in a real Facebook account yet. That waits on registering the callback URLs in the Meta app, a few minutes in a dashboard. When it runs end to end I’ll update this post, whichever way it goes.