能否将自有SQL Server数据库与Google Identity Platform集成构建自定义OIDC身份提供商？

Google Identity Platform Integration #

First off, let’s address your Google Identity Platform (GIP) question directly: GIP doesn’t natively support connecting a custom SQL Server credential store as a primary authentication source. Its built-in identity sources are limited to social providers (Google, Facebook, etc.), Firebase Auth user pools, or external SAML/OIDC providers.

That said, there’s an indirect workaround using custom authentication flows: You’d build a lightweight backend service that first validates user credentials against your SQL Server database. If validation passes, this backend calls GIP’s APIs to generate valid OIDC ID/access tokens. Other apps would still authenticate via GIP’s standard OIDC endpoints, but the actual credential check happens against your SQL store via your middle layer. Note this is a bridge solution, not a direct integration, and requires you to maintain the middle service.

Azure & AWS Alternatives (Direct Integrations) #

If you want a more streamlined approach, both Azure and AWS offer native ways to hook up your SQL Server store:

• Azure AD B2C: This is a great fit for custom identity scenarios. You can use custom policies (Azure AD B2C’s flexible rule engine) to integrate your SQL Server database. You’d build a small API that connects to SQL Server to validate credentials, then wire that API into the custom policy’s login flow. Azure AD B2C handles all the OIDC standardization, while your API takes care of checking against your existing user store.

• AWS Cognito: Cognito supports Lambda triggers that let you inject custom authentication logic. For example, when a user attempts to log in, a Lambda function is triggered—this function connects to your SQL Server database, verifies the username/password, and signals back to Cognito whether authentication should succeed. Cognito then handles issuing OIDC tokens, so your apps can use standard OIDC flows to authenticate users against your SQL store.

Building Your Own Identity Provider? #

Before you consider building an IDP from scratch, think twice: A compliant OIDC IDP requires handling security-critical tasks like token signing, refresh token rotation, OAuth2 flow enforcement, and compliance with standards like OpenID Connect and OAuth 2.0. These are complex to implement correctly and maintain securely.

Instead, use open-source IDP solutions that let you connect your SQL Server store directly:

• IdentityServer4 (.NET): A mature, open-source IDP that integrates seamlessly with SQL Server via Entity Framework Core. You can either adapt your existing user tables to fit its models or build a custom user store that pulls credentials from your SQL database.
• Keycloak (Cross-Platform): An open-source identity management tool that supports custom user federation. You can write a custom provider (or use existing extensions) to connect Keycloak to your SQL Server database, then expose standard OIDC endpoints for your apps.

Final Recommendation #

If you prefer a managed cloud solution, go with Azure AD B2C or AWS Cognito—they offer direct, secure ways to integrate your SQL Server store without building too much custom code. If you want full control over your IDP, use an open-source tool like IdentityServer4 or Keycloak instead of building from scratch.

内容的提问来源于stack exchange，提问作者tuq