diff --git a/assets/images/oauth/JWT_konzept.png b/assets/images/oauth/JWT_konzept.png
new file mode 100644
index 0000000000000000000000000000000000000000..cdaca75607147d6e59fd2f811237fb03dd16d797
Binary files /dev/null and b/assets/images/oauth/JWT_konzept.png differ
diff --git a/docs/Detailinformationen/Authentifizierung_von_Usern.md b/docs/Detailinformationen/Authentifizierung_von_Usern.md
new file mode 100644
index 0000000000000000000000000000000000000000..599ea29cb92f885d6d32330128e520a5473b9ed5
--- /dev/null
+++ b/docs/Detailinformationen/Authentifizierung_von_Usern.md
@@ -0,0 +1,99 @@
+# Authentifizierung von Usern an Zustelldiensten
+
+Jeder Onlineantragsdienst muss bei fitconnenct registriert sein, um fitconnect Formulare darstellen und übermitteln zu können. Bei der Registrierung von Onlinediensten wird festgelegt, welche Anträge die Onlinedienste auf welchen Domains ausspielen dürfen. Im Rahmen dieses Prozesses wird für jeden Onlinedienst ein Public Key hinterlegt.
+
+Eine Registrierung eines Onlinedienstes ist über das Self-Service-Portal der FITKO möglich. (TODO: link)
+
+Wenn ein Onlinedienst nun einem User ermöglichen möchte, einen Antrag zu übermitteln, muss dieser auf Basis des zum Public Key gehörenden Private Key einen JWT Token erzeugen, der Informationen dazu enthält, welcher Onlinedienst dem User erlaubt, einen Antrag an welche Destinationen zu übermitteln. Wenn der User nun einen Antrag an den Onlinedienst übermittelt, kann das fitconnect API-Gateway nachvollziehen, von wo ein Antrag übermittelt wird und somit überprüfen, ob der User/Onlinedienst dafür autorisiert ist.
+
+
+
+### Warum ist die aonyme Authentifizierung notwendig?
+
+Im Rahme von fitconnenct soll das massenhafte absenden (spammen) von Anträgen über Ratelimiting verhindert werden und es sollen nur vertrauenswürdige Webseiten, die dem fitconnnenct Standards entsprechen, die Möglichkeit bekommen, Anträge über fitconnect zu übermitteln. Um diese Maßnahmen umsetzen und einen User über mehrere Requests hinweg sicher identifizieren zu können, ist eine Form der anonymen Authentifizierung notwendig.
+
+## Generierung des JWT-Tokens beim Onlinedienst
+
+Jedes Backend eines fitconnect Onlineantragsdienstes muss über ein Backend verfügen, welches JWT-Tokens für diese Instanz erzeugen und an den Browser des Users übermitteln kann. Es sollte dabei eine geeignete Form von Rate-Limiting, für die Ausstellung der Public Keys passend zum Usecase des Onlinedienstes implementieren. Es sollte die Menge der mit einem JWT-Token freigegebenen Destinationen minimieren. **Es dürfen in denen vom Onlineservice generierten JWT-Tokens keinen Informationen hinterlegt werden, die zur Identifikation des Users führen könnten.**
+
+### Anforderungen an das Keypair
+
+Der Onlinedienst muss zur Registrierung bei fitconnect neben den Angaben dazu, welche Destinationen er unter welchen Domains verwendenden möchte, auch noch einen Public Key eines Keypairs, das nach folgenden Standards erzeugt wurde, übermitteln:
+
+| Feld | Inhalt | **Erläuterung** |
+| ------------------ | ---------- | ------------------------------------------------------------ |
+| Hashingalgorithmus | SHA-512 | Gibt den Algorithmus der zur digitalen Signatur des Keys verwendet werden muss an. Dieser muss im Fall von fitconnect immer SHA-512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Keylänge | 4096 | Länge des zugrundeliegenden RSA-Keys. Diese entspricht der Empfehlung des BSIs für ab dem Jahr 2023. (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Signaturstandard | RSASSA-PSS | Entspricht dem Standard beschrieben in [RFC 4056](https://tools.ietf.org/html/rfc4056) und vom BSI empfohlen in [BSI TR-02102-1 Abschnitt 5.4.1.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+
+Bei der Erstellung und Signierung des Keys sind alle Regeln und Standards aus BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) zu beachten.
+
+### Anforderung an die JWT-Tokens
+
+Die vom Onlinedienst generierten JWT-Tokens müssen nach [RFC 7519](https://tools.ietf.org/html/rfc7519) über folgende Attribute verfügen:
+
+#### Header
+
+Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section-8):
+
+| Feld | Inhalt | **Erläuterung** |
+| ---- | ------ | ---------------------------------------------- |
+| typ | JWT | Es handelt sich um einen JWT-Token. |
+| alg | RS512 | Der JWT Token verwendet RSASSA-PSS und HA-512. |
+| | | |
+
+**Beispiel**
+
+```json
+{
+ "typ":"JWT",
+ "alg":"HS256"
+}
+```
+
+#### Body
+
+Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
+
+| Feld | Inhalt | **Erläuterung** |
+| ----- | ------------------------- | ------------------------------------------------------------ |
+| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
+| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte max. 2 Stunden gültig sein vgl [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)). |
+| scope | Liste von Destination-IDs | Eine Liste der Destination-IDs, für die der JWT eine Übermittlung erlaubt. |
+| sid | UUID4 der Session | Eine unique ID zur Identifizierung der Session (muss garantiert für jede Übermittlung anders sein) |
+| iss | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung am API-Gateway |
+
+**Beispiel**
+
+```json
+{ Â
+ "iat":"1620072619", Â
+ "exp":"1620079819",
+ "scope": ["b49f13e6-4e05-4ca1-9f15-45a25f2c3312", "da68af39-65cf-4c4a-a990-c6fd5e791710"],
+ "sid": "8d4dcbfd-a528-4e9b-abc3-477c4cc857aa",
+ "iss": "639c5be8-eb9c-4741-834e-4ad11629898a"
+}
+
+```
+
+
+
+## Validierung durch die Sender-API/API-Gateway
+
+Bei jedem eingegangen Antrag muss der JWT-Token des Users validiert werden, um so Missbrauch der Antragsübermittlungsschnittstelle zu verhindern und nur korrekt implementierten fitconnect-Clients Zugang zur Antragsübermittlung zu geben.
+
+Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT-Tokens von demselben Onlinedienst und mit derselben Session-ID zugegriffen werden.
+
+Das API-Gateway muss die JWT-Tokens validieren:
+
+1. Überprüfen, ob diese noch gültig sind und der JWT-Token maximal für 2h ausgestellt wurde.
+2. Mit Hilfe des Public Keys die Signatur des JWT überprüfen. (Public Key wird auf Basis des **sid** ausgewählt)
+3. Überprüfen, ob die gewünschte Destination-ID teil der in Scopes angegebenen Destination-IDs und für diesen Onlineservice freigegeben ist. (Zugangsberechtigung des Onlinedienstes)
+4. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, für die jeweilige Session-ID freigegeben ist. (Verhindern von gefälschten Onlinediensten, die nicht den fitconnect-Standards entsprechen)
+
+Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben:
+
+- sid
+- IP-Addresse des Users
+- Website von der der Antrag übermittelt wird bzw. das Fehlen eines Referers
+- Onlineservice-ID
\ No newline at end of file
diff --git a/docs/Detailinformationen/Encryption_Key_Requirements.md b/docs/Detailinformationen/Encryption_Key_Requirements.md
index d9b6ea2fa573ac99c741418c96c59f7b2c49153e..81d47f21ebb5aadfc32d74e8e75f1091d6742d92 100644
--- a/docs/Detailinformationen/Encryption_Key_Requirements.md
+++ b/docs/Detailinformationen/Encryption_Key_Requirements.md
@@ -30,7 +30,7 @@ Bei der Erstellung und Signierung der Zertifikate sind alle Regeln und Standards
- Sie müssen eine Verwaltungs-PKI sein, sprich das [Wurzelzertifikat muss vom BSI stammen.](https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/Verwaltungs-PKI/Wurzelzertifizierungsstelle/wurzelzertifizierungsstelle_node.html;jsessionid=E33702EEFB110FA230DDA266C9512436.internet471)
- Sie müssen über CRL Distribution Points (siehe 8.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) ) verfügen.
-- Sie müssen einen OCSP-Endpunkt (siehe 8.5.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) mit signierten Antworten nach [RFC 6125](https://tools.ietf.org/html/rfc6125) bereitstellen.
+- Oder sie müssen einen OCSP-Endpunkt (siehe 8.5.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) mit signierten Antworten nach [RFC 6125](https://tools.ietf.org/html/rfc6125) bereitstellen.
### Zusammensetzung des JSON Web Keys zur Verschlüsselung