[oMatej]

Próbuję stworzyć własny OAuth serwer, ale nie jestem pewien czy to w jaki sposób chciałbym zbudować bazę danych ma jakiś większy sens, a także tego, czy dobrze rozumiem sposób, w jaki miałyby być obsługiwane poszczególne sposoby autoryzacji użytkowników / klientów.

Aktualnie mam w ten sposób wyglądający schemat bazy danych:
https://i.imgur.com/CHuwz5f.png
Chciałbym, żeby ten serwer autoryzacyjny wspierał obecnie trzy sposoby autoryzacji: Authorization Code, Client Credentials oraz Resource Owner Password Credentials.

1. Authorization Code


2. Client Credentials


3. Resource Owner Password Credentials


---

W przypadku 1. i 3., access_token jest powiązany z kontem użytkownikiem. Zakładając, że miałby zawierać informacje o oauth_scopes, do których ma dostęp, byłyby to elementy wspólne między uprawnieniami użytkownika oraz klienta.

W przypadku 2., access_token nie miałby żadnych informacji na temat użytkownika.

---

Jak w takiej sytuacji powinna wyglądać obsługa ról użytkownika? Ok, mamy te oauth_scopes przypisane do klienta i do konta użytkownika, ale one chyba bardziej definiują dostęp do konkretnych zasobów. Co z rolami typu admin / menedżer / etc, definiującymi np. do jakich podstron klient powinien mieć dostęp?

Jak powinna wyglądać autoryzacja zapytań w mikroserwisach? Przeglądarka użytkownika komunikuje się z API. API ma dostęp do kilku innych mikroserwisów. Co, jeśli te mikroserwisy komunikują się z innymi, które są gdzieś jeszcze bardziej zagnieżdżone? API powinno mieć do nich dostęp? Czy API powinno mieć dostęp tylko do mikroserwisów, z którymi się komunikuje bezpośrednio? Co wtedy ze scopem? W końcu użytkownik ma swoje oauth_scopes, API ma swoje i wyodrębniamy tylko wspólne elementy, więc te głębiej zagnieżdżone mikroserwisy mogą już nie znać wszystkich uprawnień użytkownika.

Pewnie o czymś zapomniałem, więc jeśli ktoś miałby jakieś inne sugestie / uwagi / cokolwiek, byłbym wdzięczny!

#webdev #javascript #nodejs

[xetrov]

@oMatej: nie pomogę, ale ten obrazek powinien być w tutorialach do OAutha podpisany mniej więcej jako oauth-is-easy.jpg ( ͡° ͜ʖ ͡°)

[oMatej]

@xetrov: jak teraz tak na to patrzę, to w sumie widzę, że zapomniałem między innymi o sytuacji, w której aplikacja zewnętrzna w adresie przekaże scope=x,y,z.

W takiej sytuacji powinna chyba powstać relacja między access_tokenem, a oauth_scopes. No ale właśnie - skoro ja chciałbym używać JWT, nie mam w bazie tabeli dla tokenów.

A i tak pewnie nie przewidziałem lub źle podszedłem do dziesiątek innych rzeczy (╥

[Zaszczyk]

@oMatej: ja skorzystałem z tego: https://github.com/thephpleague/oauth2-server i oszczędziło mi to sporo pracy :)

[oMatej]

@Zaszczyk: tak, też to widziałem. Widziałem też implementacje, które z tego korzystają (m.in. Laravel Passport). Niestety, problemem jest - przynajmniej w mojej opinii - ubogość, jeśli chodzi o schematy baz danych (ewentualnie same migracje, jak np. w Laravelu). Najgorsze jest to, że porównując różne implementacje - każda wygląda zupełnie inaczej, przez co strasznie ciężko jest się połapać w tym co jest takim "must have".

Stąd mój schemat. Jest on takim

[Zaszczyk]

@oMatej: nie zobaczyłem tagów javascript i nodejs, dlatego podesłałem Ci tę bibliotekę, sorry :) Ja używając tej biblioteki zaimplementowałem u siebie sytuacje 3. z Twojego opisu. Ze względu na to, że użytkownik loguje się do swojego konta, to w ogóle nie skorzystałem ze scope - nie była mi potrzebna ta funkcjonalność.

Co do ról użytkownika, to oauth2 tego nie obsługuje. Role i dostęp do poszczególnych akcji to ACL - powinna

[oMatej]

@Zaszczyk: tak, wiem, że OAuth nie powinien handlować rolami. Ale chciałbym umieścić je również w access_tokenie, żeby przeglądarka użytkownika też miała do nich dostęp, a przy okazji pozostałe mikroserwisy nie musiały odpytywać o role bazy danych przy każdym zapytaniu.

Jeśli chodzi o komunikację wewnętrzną - ok, przekazujesz jakiś tam token jako nagłówek. Ale co teraz z tokenem użytkownika? Jakiś głębiej zagnieżdżony mikroserwis w ogóle go nie dostaje? Więc zakładasz,