OAuth2

Prenly obsługuje OAuth2 z lub bez rozszerzenia OpenID Connect (OIDC), o ile serwer autoryzacji jest zgodny ze specyfikacją OAuth2 RFC 6749. Prawdopodobnie potrzebny będzie serwer autoryzacji obsługujący OIDC.

Prenly obsługuje tylko przyznawanie autoryzacji Authorization Code.

Klientem, którego Prenly będzie używać w przepływie OAuth2, jest organ aplikacji e-papieru (implementacja techniczna, która decyduje, w jaki sposób uwierzytelnianie i autoryzacja są obsługiwane przez aplikację e-papieru w backendzie Prenly).

Prenly musi wiedzieć kilka rzeczy, aby móc działać jako klient dla przepływu autoryzacji:

- Opcjonalnie*. Wybrany emitent.
Jest to obowiązkowe tylko wtedy, gdy chcesz korzystać z rozszerzenia OpenID Connect ID token claim.

- Obowiązkowe. Identyfikator klienta, którego ma używać organ Prenly.

- Obowiązkowe. Klucz tajny klienta, który ma być używany przez organ Prenly podczas wymiany udzielonej autoryzacji na token dostępu podczas uwierzytelniania organu Prenly (klienta).

- Opcjonalne. Zakres. Możesz wybrać, aby Prenly używał oddzielonej spacjami listy zakresów definiujących uprawnienia wydanego tokena. Zakresy będą używane z punktem końcowym autoryzacji.

- Opcjonalnie. Stan. Prenly obsługuje generowanie stanu w żądaniu autoryzacji. Możesz pozwolić Prenly wygenerować stan lub sprawić, by organ go pominął.

- Obowiązkowe. Punkt końcowy autoryzacji. Urząd Prenly przekieruje agenta użytkownika do tego punktu końcowego, aby zainicjować przepływ autoryzacji z serwerem autoryzacji poprzez zalogowanie użytkownika w celu uzyskania przyznania kodu autoryzacji.

- Obowiązkowe. Punkt końcowy tokena. Organ Prenly podejmie próbę wymiany kodu autoryzacji użytkownika na token dostępu lub, jeśli serwer autoryzacji to obsługuje (co jest zdecydowanie zalecane), wymieni token odświeżania użytkownika na nowy token dostępu.

Metoda uwierzytelniania. Domyślnie Prenly używa metody uwierzytelniania klienta OIDC client_secret_basic podczas uwierzytelniania z punktem końcowym tokena serwera autoryzacji. Prenly obsługuje również metodę uwierzytelniania klienta client_secret_post. Powiadom Prenly, jeśli potrzebujesz tej drugiej metody, w przeciwnym razie zostanie użyta domyślna metoda uwierzytelniania.

- Zalecane. Zewnętrzny adres URL do wylogowania użytkownika. Urząd Prenly użyje wybranego agenta użytkownika bieżącego użytkownika do zdalnego wylogowania użytkownika na serwerze autoryzacji.
Prenly może używać symboli zastępczych w adresie URL podczas tworzenia żądania autoryzacji w celu wylogowania użytkownika, podając następujące informacje:

◦ Identyfikator klienta;
◦ URI powrotu wylogowania;
URI błędu wylogowania;

Należy pamiętać, że stan nie może być używany.
Przykładem parametru zapytania zwrotnego URI jest "post_logout_redirect_uri".

Obecnie dla adresu URL wylogowania obsługiwana jest tylko metoda HTTP GET.

Identyfikator użytkownika

Urząd Prenly musi wiedzieć, jak wyodrębnić unikalny identyfikator użytkownika po pomyślnym autoryzowaniu użytkownika przez serwer autoryzacji.

Ten unikalny identyfikator użytkownika, jeśli korzystasz z interfejsu API Prenly Remote authority, jest parametrem żądania `uid` podczas żądania informacji podsumowujących użytkownika.

Możesz wybrać jedną z następujących metod:

- Z właściwości w odpowiedzi punktu końcowego tokenu JSON. Jeśli wybierzesz tę metodę, musisz poinformować nas o wybranej nazwie właściwości zawierającej identyfikator użytkownika.

- Z oświadczenia OpenID Connect "sub" w podpisanym tokenie ID (zwróconym przez właściwość odpowiedzi tokenu "id_token").
Aby móc wyodrębnić identyfikator użytkownika, należy również podać:

◦ Wymagane. Zewnętrzny adres URL do kluczy publicznych w celu walidacji tokenów ID. Ten adres URL musi zawierać zestaw kluczy internetowych JSON zgodnie ze standardami JWT, które mogą być określane jako JKU lub JWKS.
Opcjonalnie. Nazwa właściwości w odpowiedzi na dane użytkownika, która zawiera numer klienta.

- Z odpowiedzi właściwości "sub" z punktu końcowego UserInfo.
Aby użyć tej metody, należy również podać:

◦ Wymagane. Adres URL punktu końcowego UserInfo. Punkt końcowy służy do pobierania podstawowych informacji o użytkowniku przy użyciu tokenu dostępu użytkownika w celu autoryzacji żądania.
Opcjonalne. Nazwa właściwości w odpowiedzi na dane użytkownika, która zawiera numer klienta.

Serwer zasobów

Możesz wybrać serwer zasobów obsługiwany przez Prenly lub skontaktować się z nami pod adresem hello@prenly.com, aby złożyć wniosek do Prenly o obsługę określonego serwera zasobów jako zadanie integracji, które Prenly może obsługiwać w oparciu o płatne zadanie programistyczne.

Po wyjęciu z pudełka, Prenly obsługuje Prenly Remote authority API od wersji 1.4 jako serwer zasobów. Zobacz nasze ogólne informacje o Prenly Remote authority API, aby zapoznać się z koncepcją tego API. Aby zaimplementować Prenly Remote authority API jako serwer zasobów, zapoznaj się ze specyfikacją API dla punktu końcowego /oauth2/getUser.

"Zasobem", którego Prenly żąda od serwera zasobów, jest lista produktów subskrypcji powiązanych z użytkownikiem. Produkty, w postaci kodu produktu, wskazują status subskrypcji użytkownika, gdzie każdy kod jest skonfigurowany do przyznawania dostępu do odczytu publikacji w aplikacji e-papieru.

Aby przyznać prawidłowy dostęp do odczytu w zależności od produktu subskrypcji, należy również poinformować Prenly, do których publikacji kod produktu upoważnia do odczytu. Każdy nieznany produkt zostanie zignorowany.

Dedykowany serwer zasobów może nie być potrzebny...

Prenly może całkowicie pominąć tradycyjny serwer zasobów, jeśli punkt końcowy UserInfo jest w stanie ujawnić status subskrypcji właściciela zasobu - użytkownika.

Jeśli twój punkt końcowy UserInfo jest w stanie to zrobić, wszystko, co będziesz musiał podać, to roszczenie (nazwa właściwości) w danych JSON odpowiedzi punktu końcowego UserInfo.

Wartość roszczenia musi być listą (tablicą) ciągów JSON. Każdy element listy reprezentuje kod produktu subskrypcji.

Podaj informacje

Po uzyskaniu wszystkich wymaganych informacji skontaktuj się z obsługą klienta Prenly pod adresem hello@prenly.com. Następnie zespół skonfiguruje uprawnienia Prenly wybranej aplikacji e-paper do korzystania z OAuth2.