Ci sono molti sistemi, in particolare sistemi STS / federazione, che fanno così:
- un reclamo che descrive l'utente in modo univoco
- assortimento di attestazioni che descrivono cose concettuali generali a cui (e altri) hanno accesso
I dati "profilo" dell'utente all'interno dell'app non possono tradurre in / dalla fonte di autenticazione che stai utilizzando e non puoi utilizzare gli stessi endpoint in qualsiasi momento o tutti gli utenti.
Se conoscevi la vecchia autenticazione Forms è analogo al nome utente & il modello dei ruoli e molte delle cose incorporate appaiono ancora così se usi System.Security.Claims.ClaimTypes di nome e ruolo in modo appropriato.
Né il vecchio né il nuovo modello ti hanno dato un gran daffare per la rivendicazione o l'ereditarietà del ruolo, ma non è particolarmente difficile da implementare e l'implementazione ti consente di ridurre il volume di attestazioni o ruoli che devi tenere gioca dalla richiesta alla richiesta.
Se la tua applicazione ha bisogno di tenere traccia di un compleanno, ma non ha bisogno di usarlo in un meccanismo di sicurezza, allora non ha alcun vantaggio nel mantenerlo nella raccolta dei reclami. Inseriscilo in un set di dati del profilo separato o qualcosa del genere.
Se la tua applicazione ha bisogno di ottenere il compleanno come reclamo da un altro sistema, allora stai cercando qualcosa di più come la personalizzazione di federatedAuthentication o il fatto che il reclamo extra persista.