@finito: Przecież wystarczy uznać, ze każdy użytkownik, który się uwierzytelnił za pomocą Google to "zwykły użytkownik". Jeżeli nie ma jeszcze konta w serwisie, to każesz mu uzupełnić czego tam potrzebujesz i wszystko. Kodem ci nie odpowiem, .NET nie moja bajka, ale musi tam być coś w rodzaju "identified", czy inne "signed"..
I jeszcze raz,
Całe IAM (Identity and Access Management) składa się z 3 podstawowych elementów:
- Uwierzytelnianie (authentication) potwierdzenie tożsamości użytkownika. To może dać ci Google bezpośrednio z Google API, musisz oczywiście zrobić implementację ich flow, czyli dorobić guzik, który przekieruje gdzieś tam, jak użytkownik się zaloguje to go przekieruje znowu na twoją witrynę, ale już z odpowiednim tokenem OAuth, tego tokena użyjesz, żeby zdobyć token krótkoterminowy itd...
- Autoryzacja (authorization). Wiesz już jaki to użytkownik, ale musisz skądś pobrać dane co może zrobić w systemie. Może to być model RBAC albo ADAC, pytasz o pierwszy (role). Gdzieś informacje o tym że typ ma nadaną role
[X, Y, Z]
musisz przechowywać.
- Kontrola dostępu - czyli aplikacja na podstawie roli || atrybutów użytkownika musi go gdzieś wpuścić, albo walnąć 403 w twarz.
I jadąc po kolei:
- To robić google. Sensowniej jest użyć czegoś bardziej złożonego, co pozwoli użyć Google, login/poassword, Facebook, Git.... Oczywiście możesz to też zaimplementować sam, albo użyć jakiegoś Keycloak, czy innego gotowego softu
- Tego już Google samo z siebie ci nie da. Możesz użyć jakiegoś gotowego rozwiązania SaaS (Firebase, Auth0), albo znowu Keycloak
- To zawsze jest rola aplikacji i trzeba to zaimplementować w kodzie, można oczywiście wspomóc się biblioteką. Możesz kontrolować wyłącznie role, ale w praktyce zawsze coś tam dodatkowo trzeba zrobić. Jeżeli masz to forum to np. nie chcesz, żeby ktoś z rolą user miał dostęp do wszystkich profili, więc musisz sprawdzić przynajmniej id użytkownika na poziomie dostępu do konkretnej encji.
Konkretne flow AIM są bardziej złożone, ale ogólnie:
- uwierzytelniasz się, dostajesz token, który potwierdza tylko i wyłącznie twoją tożsamość
- strzelasz do drugiego serwisu za pomocą tego tokena, jako zwrotka dostajesz kolejny token, który zawiera dodatkowe atrybuty, np. role
- tokena z autoryzacją używasz do strzelania w konkretne endpointy, które na podstawie tego, co im dostarczasz wpuszczają cię, albo nie
Dzięki temu jak skonstruowane są tokeny, nie ma potrzeby, żeby usługi cokolwiek o sobie wiedziały, a jedynie potrafiły potwierdzić integralność dostarczonych tokenów.
Odpowiadając już konkretnie na:
Jednak jeśli owy zwykły "jeszcze nie zarejestrowany" user "się zarejestruje" przez google, to czy on "ma" dostęp do kodu, nad którym jest [Authorize(Roles = "User")] ??
Odpowiedź brzmi: zależy jak to zaimplementujesz. Google samo w sobie nie przechowuje żadnej roli w twojej aplikacji.
autentykacja
ło panie