Oauth2 Flow

​

Grundkonzepte von OAuth 2.0

• Authorization Server: Verifiziert die Identität des Benutzers und gibt Access Tokens aus.
• Resource Server: Der Server, der die geschützten Ressourcen bereitstellt (z. B. eine API).
• Client: Die Anwendung, die auf die API zugreifen möchte.
• Resource Owner: Der Benutzer, der entscheidet, ob eine Anwendung Zugriff auf seine Ressourcen erhält.
• Access Token: Ein temporäres Token, das für den Zugriff auf die API verwendet wird.
• Refresh Token (optional): Ein langfristiges Token, das zur Erneuerung eines Access Tokens genutzt wird.

​

Grant Types

​

Authorization Code Flow (mit oder ohne PKCE)

• Einsatzbereich: Webanwendungen & mobile Apps
• Sicherheit: Sehr hoch (Tokens werden nur im Backend verwaltet)

1. Weiterleitung zur Autorisierungsanfrage: Die Anwendung leitet den Benutzer auf die Anmeldeseite des Autorisierungsservers weiter. Hier gibt die Anwendung an, welche Berechtigungen (Scopes) sie benötigt.
2. Benutzerauthentifizierung und Zustimmung: Der Benutzer meldet sich beim Autorisierungsserver an und wird gefragt, ob er der Anwendung den gewünschten Zugriff gewähren möchte.
3. Erhalt des Autorisierungscodes: Nach erfolgreicher Authentifizierung wird der Benutzer zurück zur Anwendung geleitet. Dabei wird ein einmaliger Autorisierungscode übergeben.
4. Austausch des Codes gegen ein Zugriffstoken: Die Anwendung sendet den erhaltenen Code zusammen mit einem geheimen Schlüssel an den Autorisierungsserver. Falls die Anfrage gültig ist, stellt der Server ein Access Token aus.
5. Zugriff auf geschützte Ressourcen: Mit dem erhaltenen Access Token kann die Anwendung nun auf geschützte APIs zugreifen und im Namen des Benutzers Daten abrufen oder Aktionen durchführen.

​

Proof Key for Code Exchange (PKCE)

• Der Client generiert einen zufälligen Code Verifier (eine lange, zufällige Zeichenkette).
• Daraus wird eine Code Challenge abgeleitet (eine transformierte Version des Verifiers, meist als SHA-256 Hash).
• Beim Austausch des Autorisierungscodes gegen ein Access Token muss der Client den ursprünglichen Code Verifier mit senden.
• Der Server überprüft die Challenge und stellt das Access Token nur aus, wenn die Werte übereinstimmen.

​

Erweiterungen des Authorization Code Flow

1. Refresh Token für langfristigen Zugriff: Damit sich ein Benutzer nicht ständig neu authentifizieren muss, kann zusätzlich ein Refresh Token angefordert werden. Dies ermöglicht es der Anwendung, ohne erneute Benutzereingabe neue Access Tokens zu erhalten. Hierfür ist der Scope offline notwendig.
2. ID Token für Benutzerinformationen (OpenID Connect): Falls die Anwendung auch Informationen über den angemeldeten Benutzer benötigt, kann ein ID Token angefordert werden. Dieses wird als JWT (JSON Web Token) ausgestellt und enthält beispielsweise die Benutzer-ID, E-Mail-Adresse oder weitere Identitätsattribute. Hierfür ist der Scope openid notwendig.
3. Scopes zur Steuerung der Berechtigungen: Der Autorisierungsprozess kann durch verschiedene Scopes gesteuert werden. Diese definieren, welche Daten oder Funktionen der Benutzer der Anwendung freigibt.

​

Beispiel

1. Benutzer wird zur Autorisierung weitergeleitet

GET https://oauth2.coreapi.io/oauth2/auth
    ?response_type=code
    &client_id=client123
    &redirect_uri=https://my-app.com/callback
    &scope=openid offline entitlements.read
    &state=randomString

2. Benutzer meldet sich an Der Benutzer wird zum Login-Formular von Fynn weitergeleitet. Nach der Anmeldung fragt Fynn, ob die Anwendung Zugriff erhalten darf.

GET https://my-app.com/callback?code=AUTH_CODE&state=randomString

3. Anwendung tauscht den Code gegen ein Access Token Die Anwendung sendet nun eine POST-Anfrage an den Autorisierungsserver:

POST https://oauth2.coreapi.io/oauth2/token
Content-Type: application/x-www-form-urlencoded

client_id=client123
&client_secret=superSecret
&grant_type=authorization_code
&code=AUTH_CODE
&redirect_uri=https://my-app.com/callback

{
    "access_token": "...",
    "expires_in": 3600,
    "refresh_token": "...",
    "id_token": "...",
    "scope": "...",
    "token_type": "Bearer"
}

​

Refresh Token

POST https://oauth2.coreapi.io/oauth2/token
Content-Type: application/x-www-form-urlencoded

client_id=client123
&client_secret=superSecret
&grant_type=refresh_token
&refresh_token=abcd1234
&scope=offline openid entitlements.read

{
    "access_token": "...",
    "expires_in": 3600,
    "refresh_token": "...",
    "id_token": "...",
    "scope": "...",
    "token_type": "Bearer"
}

​

Scopes

​

OpenID Connect

​

ID Token

• sub (Subject) – Eindeutige Kennung des Benutzers
• name – Vollständiger Name des Benutzers
• email – E-Mail-Adresse des Benutzers
• iat (Issued At) – Zeitpunkt, zu dem das Token ausgestellt wurde
• exp (Expiration) – Ablaufzeit des Tokens
• iss (Issuer) – Identitätsanbieter (IdP), der das Token ausgestellt hat
• aud (Audience) – Die Zielanwendung, für die das Token bestimmt ist

{
  iss: "https://oauth2.coreapi.io",
  sub: "some-identity-id",
  aud: "some-client-id",
  exp: 1311281970,
  iat: 1311280970,
  nonce: "KxSty13b2L",
  name: "Jane Doe",
  given_name: "Jane",
  family_name: "Doe",
  email: "jane@example.org",
  email_verified: true,
}

​

Validierung ID Token (JWK)

​

OpenID Connect Logout

​

OpenID Connect Front-Channel Logout 1.0

• Wenn sich ein Benutzer abmeldet, leitet Fynn den User-Agent (Browser) an die registrierte Logout URI weiter.
• Die OAuth2-Client-Anwendung kann den Benutzer dann auch in deinem eigenen System abmelden, z. B. durch:
  • Löschen eines Authentifizierungs-Cookies
  • Invalidieren der Benutzersitzung

​

OpenID Connect Back-Channel Logout 1.0

• iss (Issuer) – Identifikator des ausstellenden OpenID-Providers: https://oauth2.coreapi.io oder https://oauth2.preview.coreapi.io
• aud (Audience) – Die Client-ID des OAuth2-Clients, für den dieses Logout-Token bestimmt ist.
• iat (Issued At) – Zeitpunkt, zu dem das Token ausgestellt wurde. Kann verwendet werden, um das Alter des Tokens zu bestimmen.
• jti (JWT ID) – Eindeutige Kennung des JWTs, um Replay-Angriffe zu verhindern. Das Token sollte nur einmal verwendet werden.
• events – Enthält den Eintrag http://schemas.openid.net/event/backchannel-logout. Dies deklariert, dass das JWT ein Logout-Token ist. Der entsprechende Wert MUSS ein JSON-Objekt sein und SOLLTE sein (leeres JSON-Objekt).
• sid (Session ID) – Eine Sitzungs-ID, die eine bestimmte Sitzung mit einem ID-Token verknüpft. Diese wird beim Logout-Aufruf als Parameter übergeben.