Oauth2/openid: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(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 ü…“)
 
Zeile 1: Zeile 1:
 
=Oauth2=
 
=Oauth2=
 
=Access Token=
 
=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.
+
*Access Token wird genutzt um sich auf den Resource Server zuzugreifen
Refresh Token
+
*Mit dem Parameter Scope können Berechtigungen festgelegt werden  
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.
+
*Access Token hat eine zeitlich begrenzte Gültigkeit
 
+
=Refresh Token=
 
+
*Refresh Token um ein neuen Access Token erlangen
 +
*Refresh Token hat eine zeitlich begrenzte Gültigkeit
  
 
==Abstrakter OAuth-2.0-Protokollfluss==
 
==Abstrakter OAuth-2.0-Protokollfluss==

Version vom 31. Mai 2021, 13:14 Uhr

Oauth2

Access Token

  • Access Token wird genutzt um sich auf den Resource Server zuzugreifen
  • Mit dem Parameter Scope können Berechtigungen festgelegt werden
  • Access Token hat eine zeitlich begrenzte Gültigkeit

Refresh Token

  • Refresh Token um ein neuen Access Token erlangen
  • Refresh Token hat eine zeitlich begrenzte Gültigkeit

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