feat: add third party integrations

[lfleischmann]

Description

Adds support for OAuth-based social/third party login. First supported providers are Google and GitHub only.

Implementation

• New thirdparty/auth API endpoint which redirects to the third party provider.
  • Provider implementations build authorization code endpoint URL for the respective provider and redirect.
• New thirdparty/callback API endpoint, which is called by the third party provider with an authorization code (or an error).
  • Provider implementations exchange the authorization code for an access token and use this access token to retrieve user data.
• Provider user data is then used in the main logic ( linking.go) for determining whether an account has to be created with Hanko and linked to a provider. Third party provider account links are persisted as identities that are in turn linked to an email address. Main requirements for the linking logic were:
  • Do not allow third party provider sign-in for third party account with the same email as an existing account.
  • When an email that is linked to a third party account is deleted, also delete the identity (because otherwise the user could sign in using the third party provider, but not use the "regular" Hanko login with said email) - this is currently solved through a delete cascade on the email FK constraint in the identity schema. Drawback is that we lose possibility for more granular audit logs: when you delete an email, audit logs will tell you just that, but not that an identity was removed.
  • When a user updates her primary mail with the third party provider and that email does not exist yet with Hanko, the email will be created and linked to the third party account.

Tests

I could not get a grasp on how to use our "fake" persistence layer to properly test a majority (i.e. the "linking") of the code. This "fake" layer does not accurately mimic what our real DB layer does. More specifically: it cannot fetch associations (unless they are refactored/rebuilt such that they can - I tried that, I gave up).

How to test

• Follow the guides in the docs, i.e. create client app + credentials with the respective provider, configure the backend, run quickstart

Additional context

• Because identities are linked to an email address, an identity can potentially be linked to an unassigned email address.
• Only one third party account can be currently linked to an email.
• No E2E tests

[bjoern-m]

Currently the new third party sign in buttons don't have a loading state. When I click one of them it takes a while on my end before I get redirected (~3 sec). Would suggest to add a loading state, because I think it would feel a bit more dynamic. Also the other input elements should be disabled.

[bjoern-m]

Should we export the ThirdPartyError via the index.ts file of the frontend SDK?

[lfleischmann]

Should we export the ThirdPartyError via the index.ts file of the frontend SDK?

Yes, I think we should.

[lfleischmann]

Should we export the ThirdPartyError via the index.ts file of the frontend SDK?

37d6bd1

[lfleischmann]

Currently the new third party sign in buttons don't have a loading state. When I click one of them it takes a while on my end before I get redirected (~3 sec). Would suggest to add a loading state, because I think it would feel a bit more dynamic. Also the other input elements should be disabled.

28179f0

[bjoern-m]

Nicely done! Approved from my side.