Neilk1021 opened a new issue, #6718:
URL: https://github.com/apache/texera/issues/6718

   ### Feature Summary
   
     ### Current Problem                                                        
                                                                           
     Authentication data is stored directly on the `"user"` table: `password`, 
`google_id`,                                                        
     and `google_avatar`, gated by a `ck_nulltest` CHECK ("password OR 
google_id must be set").                                                    
     This couples *who a user is* (identity) to *how they authenticate* 
(credentials), which has                                                   
     several consequences:                                                      
                                                                   
                                                                                
                                                                   
     - **A user can only ever have one external identity.** `google_id` is a 
single column, so a                                                   
       user cannot link more than one provider, and adding a new provider 
(Facebook, GitHub, SSO…)                                                 
       means adding yet another column + widening the `ck_nulltest` CHECK each 
time.                                                               
     - **Provider-specific fields leak into the identity model and the JWT.** 
`googleId` /                                                         
       `googleAvatar` are baked into `jwtClaims`, the `SessionUser`, the 
frontend `User` type, and                                                 
       several resources — none of which should care which provider a user 
logged in with.                                                         
     - **Login provisioning logic is duplicated per provider.** Each OAuth 
resource re-implements                                                  
       its own "find user by provider id → else by email → else create → attach 
credential" flow.  
   
    ### High level feature                                                      
                                                           
     Separate identity from credentials so that:                                
                                                                   
                                                                                
                                                                   
     1. The `"user"` table holds only identity/profile data; a dedicated table 
holds one row per                                                   
        `(user, provider)` credential, allowing a user to have multiple linked 
providers.                                                          
     2. Adding a new auth provider requires **no schema change** — only a new 
verifier that maps the                                               
        provider's token to a common profile shape.                             
                                                                   
     3. The JWT and the user model are **provider-agnostic** (a single 
`avatar`, no `googleId`).                                                   
     4. **Facebook login** is supported as the first proof that the new model 
is pluggable.                                                        
                                                                                
                                                                                
                        
                                                                  
   ### Related Discussion(s):
   Proposal #6716 and #6717
           
   
   ### Proposed Solution or Design
   
     ### Scope / acceptance criteria                                            
                                                                   
     - [ ] New credential table keyed by `(uid, provider_type)`, with a 
constraint enforcing the                                                   
           correct credential shape per provider (password for local, external 
id for OAuth).                                                      
     - [ ] A migration moves existing `password` / `google_id` / 
`google_avatar` data into the new                                               
  
           model without data loss, and drops the columns + `ck_nulltest` from 
`"user"`.                                                           
     - [ ] Local, Google, and Facebook login all provision users through one 
shared code path.                                                     
     - [ ] JWT carries a provider-neutral `avatar` claim; 
`googleId`/`googleAvatar` removed                                               
         
           end-to-end (backend + frontend).                                     
                                                                   
     - [ ] Facebook login works end-to-end (client-id endpoint, token 
verification, provisioning).                                                 
     - [ ] Tests cover the provisioning matrix and the JWT claim change.        
                                                                   
                                                                                
                                                                   
     ### Out of scope                                                           
                                                                   
     - Additional providers beyond Facebook (GitHub, SAML/SSO) — enabled by 
this change but not                                                    
       implemented here.                                                        
                                                                   
     - Account-linking UI (letting a signed-in user attach a second provider 
from settings).                  
   
   ### Affected Area
   
   Other


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to