Oauth2/openid

Aus xinux.net
Version vom 31. Mai 2021, 13:10 Uhr von Niklas.guenauer (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „=Oauth2= =Access Token= Um auf geschützte Daten auf dem Resource Server zuzugreifen, muss ein Access Token vom Client als Repräsentation der Autorisierung ü…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Oauth2

Access Token

Um auf geschützte Daten auf dem Resource Server zuzugreifen, muss ein Access Token vom Client als Repräsentation der Autorisierung übermittelt werden. Mittels des Parameters scope können die mit dem Access Token verbundenen Berechtigungen festgelegt werden. Zum einen kann der Client gewünschte Berechtigungen beim Authorization Server anfragen, zum anderen teilt dieser die gewährten Berechtigungen mit. Das Access Token hat eine zeitlich begrenzte Gültigkeit. Refresh Token Ein Refresh Token kann dazu verwendet werden, beim Authorization Server ein neues Access Token anzufragen, falls das Access Token abgelaufen oder ungültig geworden ist.


Abstrakter OAuth-2.0-Protokollfluss

  • Client fordert eine Autorisierung vom Resource Owner an
  • Client erhält eine Autorisierungsgenehmigung vom Resource Owner
  • Autorisierung kann über einen der vier Autorisierungsgenehmigungsprozesse
  • Client fordert ein Access Token vom Authorization Server an.
  • Er nutzt die Autorisierungsgenehmigung vom Resource Owner.
  • Authorization Server authentisiert den Client (permission to ask)
  • prüft die Autorisierungsgenehmigung des Resource Owners.
  • Ist diese erfolgreich, stellt er ein Access Token aus.
  • Client fragt die geschützten Daten beim Resource Server an.
  • Zur Authentisierung benutzt er das Access Token.
  • Der Resource Server prüft das Access Token und stellt, die gewünschten Daten zur Verfügung.

Ouath2-Protocol-Flow.png

Links