Prenly unterstützt OAuth2 mit oder ohne OpenID Connect-Erweiterung (OIDC), solange der Autorisierungsserver der OAuth2-Spezifikation RFC 6749 folgt. Sie werden wahrscheinlich einen Autorisierungsserver benötigen, der OIDC unterstützt.

Prenly unterstützt nur die Autorisierungserlaubnis Authorization Code.

Der Client, den Prenly im OAuth2-Fluss verwendet, ist die Anwendungsautorität des E-Papers (eine technische Implementierung, die entscheidet, wie Authentifizierung und Autorisierung durch die E-Paper-Anwendung innerhalb des Backends von Prenly gehandhabt werden).

Prenly muss ein paar Dinge wissen, um als Client für den Autorisierungsfluss agieren zu können:

- Optional*. Der gewählte Emittent.

Dies ist obligatorisch, wenn Sie die OpenID Connect-Erweiterung ID-Token-Claim verwenden möchten.

- Obligatorisch. Die Client-ID, die die Prenly-Autorität verwenden soll.

- Obligatorisch. Das Client-Geheimnis, das die Prenly Autorität verwenden soll, wenn sie die bereitgestellte Autorisierungserlaubnis gegen ein Zugriffstoken austauscht, wenn sie die Prenly Autorität (den Client) authentifiziert.

- Optional. Umfang. Sie können Prenly dazu veranlassen, eine durch Leerzeichen getrennte Liste von Bereichen zu verwenden, die die Berechtigung des ausgestellten Tokens definieren. Der/die Geltungsbereich(e) wird/werden mit dem Autorisierungsendpunkt verwendet.

- Wahlweise. Zustand. Prenly unterstützt die Generierung von Status in der Autorisierungsanfrage. Sie können entweder Prenly einen Status generieren lassen oder die Autorität dazu bringen, ihn zu überspringen.

- Obligatorisch. Endpunkt der Autorisierung. Die Prenly Autorität wird den User Agent zu diesem Endpunkt navigieren, um den Autorisierungsfluss mit dem Autorisierungsserver zu initiieren, indem der Benutzer angemeldet wird, um den Autorisierungscode zu erhalten.

- Obligatorisch. Token-Endpunkt. Die Prenly-Behörde versucht, den Autorisierungscode des Benutzers gegen ein Zugriffstoken auszutauschen oder, falls Ihr Autorisierungsserver dies unterstützt (was dringend empfohlen wird), das Refresh-Token des Benutzers gegen ein neues Zugriffstoken auszutauschen.

Authentifizierungsmethode. Standardmäßig verwendet Prenly die Client-Authentifizierungsmethode client_secret_basic des OIDC , wenn es sich am Token-Endpunkt des Autorisierungsservers authentifiziert. Prenly unterstützt auch die Client-Authentifizierungsmethode client_secret_post. Bitte benachrichtigen Sie Prenly, wenn Sie letztere benötigen, andernfalls wird die Standard-Authentifizierungsmethode verwendet.

- Empfohlen. Eine externe URL zum Abmelden des Benutzers. Die Prenly-Behörde verwendet den vom aktuellen Benutzer ausgewählten Benutzer-Agenten, um den Benutzer per Fernzugriff beim Autorisierungsserver abzumelden.

Prenly kann bei der Erstellung der Autorisierungsanfrage Platzhalter in der URL verwenden, um den Benutzer abzumelden, indem es die folgenden Angaben macht:

◦ Die Client-ID;

◦ Die Logout-Rückgabe-URI;

◦ Die Abmeldefehler-URI;

Bitte beachten Sie, dass der Status nicht verwendet werden kann.

Ein Beispiel für einen Rückgabe-URI-Abfrageparameter ist "post_logout_redirect_uri".

Derzeit wird nur die HTTP-Methode GET für die Abmelde-URI unterstützt.

Die Prenly-Behörde muss wissen, wie sie die eindeutige Benutzer-ID extrahieren kann, nachdem der Benutzer vom Autorisierungsserver erfolgreich autorisiert wurde.

Diese eindeutige Benutzer-ID ist, wenn Sie die API der Prenly Remote-Behörde verwenden, der Anfrageparameter "uid", wenn Sie die Benutzerzusammenfassung anfordern.

Sie können eine der folgenden Methoden wählen:

- Aus einer Eigenschaft in der JSON-Token-Endpunktantwort. Wenn Sie dies wählen, müssen Sie uns den Namen der Eigenschaft mitteilen, die die Benutzer-ID enthält.

- Aus dem OpenID Connect "sub"-Claim im signierten ID-Token (wie von der Token-Antworteigenschaft "id_token" zurückgegeben).

Um die Benutzer-ID extrahieren zu können, müssen Sie auch Folgendes angeben:

◦ Erforderlich. Die externe URL zu öffentlichen Schlüsseln zur Validierung der ID-Token. Diese URL muss ein JSON Web Key Set gemäß JWT-Standards (siehe RFC 7515) enthalten, das entweder als JKU oder JWKS bezeichnet werden kann.

◦ Optional. Der Eigenschaftsname in der Nutzdatenantwort, der eine Kundennummer enthält.

◦ Erforderlich. Muss nur den Aussteller kennen, der bei der Verifizierung des ID-Tokens mit der Angabe "iss" im ID-Token übereinstimmen muss.

Für weitere Einzelheiten siehe ID-Token.

- Aus der Antwort der Eigenschaft "sub" von einem UserInfo-Endpunkt.

Um diese Methode zu verwenden, müssen Sie auch bereitstellen:

◦ Erforderlich. Die URL des UserInfo-Endpunkts. Der Endpunkt wird verwendet, um grundlegende Informationen über den Benutzer abzurufen, indem das Zugriffstoken des Benutzers verwendet wird, um die Anfrage zu autorisieren.

◦ Optional. Der Eigenschaftsname in der Benutzerdatenantwort, der eine Kundennummer enthält.

Sie können einen Ressourcenserver wählen, den Prenly unterstützt, oder Sie können uns unter hello@prenly.com kontaktieren, um Prenly zu bitten, Ihren spezifischen Ressourcenserver als Integrationsaufgabe zu unterstützen, die Prenly auf der Grundlage einer bezahlten Entwicklungsaufgabe unterstützen könnte.

Prenly unterstützt standardmäßig die Prenly Remote Authority API ab Version 1.4 oder höher als Ressourcenserver. Siehe unsere allgemeinen Informationen über Prenly Remote authority API für das Konzept dieser API. Um Prenly Remote authority API als Ressourcenserver zu implementieren, lesen Sie bitte die API-Spezifikation für den Endpunkt /oauth2/getUser.

Die "Ressource", die Prenly vom Ressourcenserver anfordert, ist eine Liste von Abonnementprodukten, die mit dem Benutzer verbunden sind. Die Produkte in Form eines Produktcodes geben den Abonnementstatus des Benutzers an, wobei jeder Code so konfiguriert ist, dass er Lesezugriff auf Publikationen innerhalb Ihrer E-Paper-Anwendung gewährt.

Um je nach Abonnementprodukt den richtigen Lesezugriff zu gewähren, müssen Sie Prenly auch mitteilen, zu welchen Publikationen der Produktcode den Lesezugriff erlaubt. Jedes unbekannte Produkt wird ignoriert.

Sie brauchen vielleicht keinen dedizierten Ressourcenserver...

Prenly kann einen traditionellen Ressourcenserver ganz umgehen, wenn Ihr UserInfo-Endpunkt in der Lage ist, den Abonnementstatus des Ressourceneigentümers - des Benutzers - offenzulegen.

Wenn Ihr UserInfo-Endpunkt dazu in der Lage ist, müssen Sie nur den Claim (Eigenschaftsname) in den JSON-Daten der UserInfo-Endpunktantwort bereitstellen.

Der Anspruchswert muss eine JSON-Liste (Array) von Strings sein. Jedes Listenelement steht für einen Abonnement-Produktcode.

Wenn Sie alle erforderlichen Informationen haben, wenden Sie sich bitte an den Prenly-Kundendienst unter hello@prenly.com und teilen Sie die Informationen mit. Das Team wird dann die Prenly-Autorität der gewählten E-Paper-Anwendung für die Verwendung von OAuth2 für Sie einrichten.