Vereinspraxis
Angebundene Anwendungen: Vereinslogin per OAuth und OpenID Connect
Kaum ein Verein arbeitet mit einem einzigen System. Neben der Mitgliederverwaltung steht ein Forum, eine Wettkampfseite, ein Buchungswerkzeug für die Halle, vielleicht ein Wiki für die Übungsleiter. Jedes dieser Systeme hat seine eigene Benutzerliste. Wer eintritt, wird viermal angelegt. Wer austritt, bleibt dreimal drin — und zwar so lange, bis es jemandem auffällt.
Genau diese Lücke schließt die Seite Angebundene Anwendungen unter Organisation. Sie macht aus dem Vereinskonto in Methacore die eine Anmeldestelle, bei der alle anderen Systeme nachfragen: Wer kommt hier eigentlich, und darf der das?
Was das technisch ist — in zwei Sätzen
Methacore tritt als OpenID-Connect-Provider auf. OpenID Connect (kurz OIDC) ist eine dünne Schicht über OAuth 2.0: OAuth regelt, wie eine Anwendung einen zeitlich begrenzten Zugriffsschlüssel bekommt, ohne das Passwort des Nutzers zu sehen. OpenID Connect ergänzt die Antwort auf die Frage, wer der Nutzer ist — als signiertes ID-Token mit Name, E-Mail-Adresse und, wenn gewünscht, der Mitgliedschaft im Verein.
Das Wichtige daran: Das Passwort verlässt Methacore nie. Das Forum sieht es nicht, der Shop sieht es nicht. Beide sehen nur das Ergebnis einer Anmeldung, die auf der gewohnten Methacore-Anmeldeseite stattgefunden hat — mit demselben Passkey und demselben zweiten Faktor wie sonst.
Warum ein Verein das macht
Ein Konto, ein Passwort. Der häufigste Grund ist banal und trägt trotzdem am weitesten: Mitglieder merken sich keine vier Zugänge. Sie schreiben sie auf, verwenden überall dasselbe Passwort oder melden sich gar nicht an. Ein einziger Zugang wird tatsächlich genutzt.
Der Austritt wirkt überall. Wer aus dem Verein austritt, kommt in keine der angebundenen Anwendungen mehr hinein — ohne dass jemand vier Listen pflegt. Das ist kein Komfortthema, sondern eines der Rechenschaftspflicht: ein Konto, das nach dem Austritt noch drei Jahre im Vereinsforum lebt, ist ein Datenschutzproblem mit Anlauf.
Der zweite Faktor gilt einmal für alles. Vereine, die Zwei-Faktor-Authentifizierung verlangen, müssen sie nur an einer Stelle durchsetzen — in der Sicherheitsrichtlinie von Methacore. Angebundene Anwendungen erben sie automatisch, weil die Anmeldung ohnehin bei Methacore passiert.
Ämter kommen mit. Wenn im Forum nur der Vorstand einen bestimmten Bereich sehen soll, muss das Forum wissen, wer im Vorstand ist. Über den Scope memberships liefert Methacore die aktiven Ämter mit — und zwar nur die, die zum Zeitpunkt der Anmeldung tatsächlich gehalten werden. Eine abgelaufene Amtszeit verschwindet damit von selbst aus der Berechtigung.
Was man braucht, bevor man anfängt
Vier Dinge, und keines davon ist optional:
- Die Anwendung muss OpenID Connect sprechen. Nahezu jede halbwegs moderne Software kann das, oft unter Namen wie „SSO“, „OAuth2-Login“ oder „OIDC-Provider“. Kann sie es nicht, hilft diese Seite nicht weiter.
- Eine feste Rückleitungsadresse (englisch redirect URI). Die Anwendung zeigt sie in ihren eigenen Einstellungen an, meist als
https://forum.example.de/auth/callback. Diese Adresse wird zeichenweise verglichen — dazu unten mehr. - HTTPS.
httpist ausschließlich fürlocalhost,127.0.0.1und::1erlaubt, also fürs Ausprobieren auf dem eigenen Rechner. Alles andere muss verschlüsselt sein. - Das Recht „Organisation bearbeiten“. Wer Anwendungen anlegt, verteilt Zugriff auf Mitgliederdaten. Das ist bewusst kein Recht, das jeder Administrator nebenbei hat.
Eine Anwendung anlegen: die vier Felder
Im Drawer stehen genau vier Angaben. Jede davon hat eine Konsequenz, die man kennen sollte.
Name
Der Name steht auf der Zustimmungsseite, die das Mitglied vor der ersten Anmeldung sieht. Er ist damit die einzige Information, auf deren Basis das Mitglied entscheidet. „Vereinsforum“ ist gut. „App 2“ ist eine Aufforderung, auf Abbrechen zu klicken.
Art der Anwendung
Diese Wahl steht beim Anlegen fest und lässt sich später nicht ändern.
| Öffentlich (mit PKCE) | Vertraulich (mit Secret) | |
|---|---|---|
| Wofür | Handy-App, Single-Page-Anwendung im Browser | Software auf einem eigenen Server |
| Secret | keins | ja, wird einmal angezeigt |
| Warum | Der Code liegt beim Nutzer und kann kein Geheimnis verwahren | Der Server kann ein Geheimnis geheim halten |
Der Grund für die Unterscheidung: Ein Geheimnis, das in einer App auf dem Telefon liegt, ist kein Geheimnis. Es lässt sich auslesen. Eine öffentliche Anwendung weist sich deshalb allein über PKCE aus — ein Verfahren, bei dem die Anwendung zu Beginn einen Zufallswert erzeugt, dessen Prüfsumme mitschickt und den Originalwert erst beim Tokenabruf nachreicht. Wer die Anmeldung unterwegs abfängt, hat den Originalwert nicht und kann damit nichts anfangen.
Methacore verlangt PKCE in beiden Fällen. Fehlt es, endet die Anmeldung mit invalid_request. Wenn eine Anwendung eine Option „PKCE verwenden“ anbietet, muss sie eingeschaltet sein.
Rückleitungen
Hier liegt die häufigste Fehlerquelle des ganzen Verfahrens. Nach der Anmeldung schickt Methacore einen kurzlebigen Autorisierungscode an die Rückleitungsadresse. Wäre die Prüfung großzügig, könnte jemand mit einer eigenen Adresse im Aufruf diesen Code auf seinen Server umleiten und damit fremde Konten übernehmen.
Deshalb wird zeichenweise verglichen. Bei registriertem https://forum.example.de/auth/callback werden alle folgenden Adressen abgewiesen:
https://forum.example.de/auth/callback/— Schrägstrich am Endehttps://forum.example.de/auth/callback?x=1— Parameter angehängthttps://forum.example.de/auth/callback/weiter— Pfad angehängthttp://forum.example.de/auth/callback— anderes Schema
Zusätzlich gilt beim Speichern: keine Platzhalter (*), kein #-Fragment, keine eigenen Schemata wie myapp://. Eine native App nutzt stattdessen eine Loopback-Adresse, etwa http://127.0.0.1:7777/callback.
Praktischer Rat: Die Adresse kopieren, nicht abtippen. Aus der Anwendung heraus, so wie sie dort steht — inklusive oder ohne abschließenden Schrägstrich. Mehrere Adressen sind erlaubt, etwa eine für die Testumgebung und eine für den Betrieb.
Berechtigungen (Scopes)
Ein Scope ist die Antwort auf die Frage: Was darf diese Anwendung überhaupt erfahren? Es sind vier, und openid ist immer dabei.
| Scope | Was die Anwendung erfährt |
|---|---|
openid | Die dauerhafte Kennung des Kontos (sub). Pflicht — ohne ihn ist es keine Anmeldung. |
profile | Vorname, Nachname, Anzeigename, Benutzername, Profilbild. |
email | Die E-Mail-Adresse und ob sie bestätigt ist. |
memberships | Die Mitgliedschaft in diesem Verein, ob das Konto dort Administrator ist, und die aktiven Ämter. |
Die Regel lautet: so wenig wie möglich. Ein Forum, das Beiträge einem Namen zuordnet, braucht openid profile. Braucht es E-Mail-Benachrichtigungen, kommt email dazu. memberships gehört nur dorthin, wo tatsächlich nach Rolle unterschieden wird.
Was memberships nicht liefert: andere Vereine. Dass dieselbe Person nebenan im Schützenverein Kassenwart ist, geht die Anwendung des Turnvereins nichts an. Es steht genau ein Verein in der Antwort — der, dem die Anwendung gehört.
Das Secret: einmal sichtbar, danach nie wieder
Bei einer vertraulichen Anwendung erscheint das Secret direkt nach dem Anlegen — und nur dort. Gespeichert wird ausschließlich sein Hash. Das ist keine Unbequemlichkeit, sondern der Punkt: Wer die Datenbank von Methacore liest, findet kein einziges verwendbares Secret.
Praktisch bedeutet das:
- Anwendung anlegen.
- Secret sofort in die Zielanwendung eintragen oder in den Passwortmanager des Vereins legen.
- Erst dann den Drawer schließen.
Ist es verloren, hilft nur Secret erneuern. Das alte gilt ab diesem Augenblick nicht mehr; bis das neue in der Anwendung steht, scheitert deren nächster Tokenabruf mit invalid_client. Diese Aktion also nicht am Sonntagabend ausführen, sondern dann, wenn man auch nachlegen kann.
Worauf man achten muss
Nur Angehörige dieses Vereins kommen hinein. Eine Anwendung gehört dem Verein, der sie registriert hat, und steht auch nur diesem offen. Herein kommen Mitglieder des Vereins und seine Administratoren. Draußen bleibt, wer ausgetreten ist — und zwar geprüft, bevor überhaupt eine Zustimmung entsteht. Wer im Dezember austritt, meldet sich im August noch an; die Prüfung schaut auf den tatsächlichen Stand, nicht auf ein Datum in der Zukunft.
Konten über sub verknüpfen, nicht über die E-Mail-Adresse. Wenn die angebundene Anwendung bereits Nutzer hat und diese zuordnen will, ist die richtige Kennung sub — die unveränderliche Konto-Id. E-Mail-Adressen wechseln. Eine Anwendung, die über die Adresse zuordnet, ordnet nach einem Wechsel falsch zu, im schlimmsten Fall dem Falschen. Wer trotzdem über die Adresse verknüpfen muss, sollte mindestens auf email_verified achten: eine unbestätigte Adresse ist ein Tippfehler oder eine fremde.
Abschalten statt löschen. Der Zustand „abgeschaltet“ beendet neue Anmeldungen sofort und lässt die Konfiguration stehen. Das ist die richtige Reaktion auf einen Verdacht: Man kann jederzeit zurück. Löschen ist endgültig — Kennung und Rückleitungen sind weg, und die Anwendung muss neu eingerichtet werden.
Ein zweimal eingelöster Code ist ein Vorfall, kein Schluckauf. Ein Autorisierungscode gilt 60 Sekunden und genau einmal. Wird er ein zweites Mal eingelöst, scheitert nicht nur der zweite Versuch — es werden auch alle Tokens widerrufen, die aus diesem Code entstanden sind. Wenn das im Betrieb auftritt, ist meist ein Wiederholungsversuch ohne Zustandsprüfung die Ursache. Oder jemand liest mit.
Die Zustimmung liegt beim Mitglied, nicht beim Verein. Jedes Mitglied sieht seine verbundenen Anwendungen in der eigenen Sicherheitsübersicht und kann sie dort entziehen. Ein Entzug macht alle Tokens dieser Anwendung sofort ungültig, auch das langlebige Refresh-Token. Der Verein kann diese Entscheidung nicht überstimmen — das ist Absicht.
Wenn es nicht klappt: die drei häufigsten Meldungen
| Was passiert | Woran es liegt |
|---|---|
| „Diese Redirect-URI ist für die Anwendung nicht hinterlegt.“ | Ein Schrägstrich, ein Parameter oder http statt https. Adresse aus der Anwendung kopieren. |
| „Diese Anwendung ist nicht registriert.“ | Tippfehler in der Kennung, oder die Anwendung wurde gelöscht. |
| „Diese Anwendung gehört zu einem anderen Verein.“ | Das angemeldete Konto ist in diesem Verein weder Mitglied noch Administrator. |
invalid_request an der Rückleitung | PKCE fehlt oder ist auf plain gestellt. In der Anwendung auf S256 umstellen. |
invalid_client beim Tokenabruf | Secret falsch oder erneuert, oder die Anwendung ist abgeschaltet. |
Auffällig und beabsichtigt: Solange Kennung und Rückleitung nicht geprüft sind, leitet Methacore nirgendwohin weiter, sondern zeigt eine Seite im Browser. Ein Endpunkt, der ungeprüft weiterleitet, ist selbst eine offene Weiterleitung.
Was das für den einzelnen Nutzer heißt
Beim ersten Mal sieht das Mitglied eine Zustimmungsseite mit dem Namen der Anwendung und den angeforderten Berechtigungen. Danach nicht mehr — bis die Anwendung eine zusätzliche Berechtigung anfordert. Dann wird erneut gefragt, und zwar nur nach der neuen.
Ab dem zweiten Mal ist die Anmeldung ein Klick, weil die Methacore-Sitzung ohnehin steht. Genau das ist der Punkt, an dem Mitglieder anfangen, die anderen Systeme des Vereins tatsächlich zu benutzen.
Häufige Fragen
Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect?
OAuth 2.0 regelt Zugriff: Eine Anwendung erhält einen zeitlich begrenzten Schlüssel für bestimmte Daten, ohne das Passwort zu kennen. OpenID Connect legt darüber eine Anmeldung: Es ergänzt ein signiertes ID-Token, das aussagt, wer sich angemeldet hat und wann. Für einen Vereinslogin braucht man beides — und deshalb spricht man in der Praxis von OIDC, auch wenn in den Masken der Software oft „OAuth2“ steht.
Brauche ich dafür einen Entwickler?
Für die Seite in Methacore nicht: Name, Art, Rückleitung, Berechtigungen, und das war es. Auf der anderen Seite hängt es an der Anwendung. Software mit einer OIDC-Maske braucht meist nur drei Angaben — Discovery-Adresse, Kennung und, bei vertraulichen Anwendungen, das Secret. Wird die Anwendung selbst gebaut, sollte sie eine erprobte OIDC-Bibliothek verwenden und nicht das Protokoll von Hand nachbauen; die Prüfung von Signatur, aud, exp und nonce ist der Teil, den man nicht selbst schreiben will.
Was passiert, wenn ein Mitglied austritt?
Der Zugang endet. Mit dem Austritt fällt der Verein aus den Mitgliedschaften des Kontos heraus, und die Prüfung findet bei jeder neuen Anmeldung statt. Bereits ausgegebene Zugriffsschlüssel laufen innerhalb einer Stunde ab, danach gelingt keine Verlängerung mehr. Es gibt keinen Nachlauf, den jemand von Hand schließen müsste.
Welche Daten bekommt die angebundene Anwendung?
Genau die, die zu den erteilten Berechtigungen gehören — nicht mehr. Ohne email keine Adresse, ohne memberships keine Ämter. Nie enthalten: Passwörter, Passkeys, Beitragsdaten, Bankverbindungen, Rechnungen. Und nie Mitgliedschaften in anderen Vereinen.
Was mache ich, wenn das Client-Secret verloren ist?
Erneuern. Nachlesen ist unmöglich, weil nur der Hash gespeichert ist. Nach dem Erneuern muss das neue Secret in die Anwendung eingetragen werden; bis dahin schlagen deren Tokenabrufe fehl. Wer das Zeitfenster klein halten will, öffnet vorher die Einstellungsmaske der Zielanwendung und erneuert dann.