🌟Add Apple and Google OAuth login flows

[jamesholcomb]

Enable users to sign up / log in using Google and Apple identity providers (OAuth 2.0 / OpenID Connect).

Site admins should be able configure the available login methods (social only, username/password or both).

This will improve the mobile web experience, user onboarding, reduce friction and allow self hosters to avoid the burden of data breaches and compromised credentials.

[da-wilky]

Absolutly! I would love to see this feature implemented, especially OpenID Connect, so organizations can hook it up with their keycloak/authentik setup!

[ethbkk1]

This is also something I’d consider very helpful to integrate the same user base..

[lukassvec]

I agree. This is would be very helpful for integrating with my main site, especially if paired with allowing hi.events to autofill attendee details for the user.

[Lord-KalEl]

OIDC is good … but if you are working on this feature, why not implementing SCIM?

SCIM is:

The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identities in cloud-based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence: make it fast, cheap, and easy to move users in to, out of, and around the cloud.

More information on:
https://scim.cloud/

Greetings,
Kal

[Sipioteo]

It would likely be better to implement OpenID Connect (OIDC) authentication with email reconciliation, so that hi.events can be easily integrated with external identity providers such as Keycloak, Zitadel, Google, Microsoft, and others.

Additionally, we could validate a powers (or similar claims) field in the OpenID response to control access. Only users with the "events" permission should be granted access to the administration interface, while other authenticated users would instead be directed to a page displaying the tickets associated with their email address.

[Lord-KalEl]

It would likely be better to implement OpenID Connect (OIDC) authentication with email reconciliation, so that hi.events can be easily integrated with external identity providers such as Keycloak, Zitadel, Google, Microsoft, and others.
OIDC is often the first step in user authentication, enabling secure login via identity providers. SCIM comes after, handling user and group lifecycle management—automatically creating, updating, or deactivating accounts across systems. While OIDC and SSO manage authentication and access, SCIM standardizes how user and group data is shared and synchronized, making configuration easier and more consistent across cloud applications. So, SCIM is not just an extension of OIDC or SSO—it’s a separate, complementary protocol focused on identity provisioning and management.

Additionally, we could validate a powers (or similar claims) field in the OpenID response to control access. Only users with the "events" permission should be granted access to the administration interface, while other authenticated users would instead be directed to a page displaying the tickets associated with their email address.

OIDC for Authentication, SCIM for Authorization Foundation

Using a powers or permissions claim in the OIDC response to control access — for example, granting admin interface access only to users with an "events" permission — is an effective runtime authorization mechanism. But the reliability of that claim depends entirely on accurate, automated identity management. That’s where SCIM comes in.

SCIM synchronizes users and their group memberships (e.g., "events", "admin", "support") from the Identity Provider (IdP) like Okta or Azure AD into your application or access proxy. These groups can then be mapped directly to claims in the OIDC token.

This means:

• When a user is added to the "events" group in the IdP, SCIM provisions them into the correct role.
• On next login, OIDC includes "powers": ["events"] in the token.
• Your app reads the claim and grants admin access — automatically.

No manual updates, no stale permissions
SCIM handles the "who should have what" — user provisioning, group assignments, deactivation.

OIDC handles the "prove who you are and what you have" — secure tokens with claims like powers.

Together, they ensure that only authorized users access sensitive interfaces — based on trusted, centrally managed identities.

• Selfhosted, secure solution: Kanidm (an IAM OpenSource solution, written in Rust).

[Sipioteo]

True, SCIM is complementary to OIDC, but it’s a different layer.

This thread is about adding login/sign-up via Google/Apple and (ideally) generic OIDC, which solves the immediate onboarding + SSO need for most deployments (including Keycloak/Zitadel/AuthentiK).

SCIM is provisioning/lifecycle (create/update/deactivate users + group sync). That’s a much bigger scope and makes sense as a separate feature request, otherwise it derails the OAuth/OIDC discussion.

If you want to pursue SCIM, I’d suggest opening a dedicated issue with concrete requirements (Users/Groups, role mapping, target IdPs, deprovisioning behavior). But for this ticket, OIDC is the relevant piece on my opinion.