Ergebnis der Suchanfrage

• Forum: Netzwerke

  AW: OAuth2 erste Schritte

    Delphi
    by Phoenix, 7. Nov 2022
  So, jetzt hab ich da nochmal drüber nachgedacht.
  
  Es gibt für solche Fälle, also die initiale Auth für Hintergrund-Dienste, aber auch um Geräte einzuloggen die keine gute/direkte Eingabemöglichkeit für die Benutzer-Credentials anbieten, noch weitere Grant-Types (flows) die man verwenden kann.
  
  Das eine ist der Device-Code Flow. Das benutzt z.B. die Amazon Prime Video App auf Samsung TVs oder...
• Forum: Netzwerke

  AW: OAuth2 erste Schritte

    Delphi
    by Phoenix, 4. Nov 2022
  Vermutlich. Ist auch eher für manuelle Tests gedacht. Für automatisierte Tests kann man ja auch keine Auth verwenden die einen Benutzer erfordert ;)
• Forum: Netzwerke

  AW: OAuth2 erste Schritte

    Delphi
    by Phoenix, 3. Nov 2022
  Auch ein Passwort-Manager greift in den Embedded Browsern nicht. Google z.B. investiert auch jede Menge Zeit und Geld darin, dass die Google-Anmeldeseite bewusst nicht in embedded Browsern funktioniert. Auch das steht in der Spec: Ein IdP-Anbieter sollte verhindern das die Login-Seite in solchen Embedded Browsern funktioniert.
  
  
  
  Wenn Du eine mit OAuth abgesicherte API testen willst, kannst...
• Forum: Netzwerke

  AW: OAuth2 erste Schritte

    Delphi
    by Phoenix, 2. Nov 2022
  Da hat Bbommel recht. Wenn es ein Hintrgrund-Dienst ist, der eigentlich keinen Benutzer am Bildschirm erfordert, dann wäre client credentials vermutlich der richtige Grant Type (ja, "Flow" stand dazu zwar mal in Spec, aber der eigentlich korrekte Begriff ist Grant Type).
  
  Das Ding ist dann aber, dass der client ja Zugriff auf Nutzerdaten (also deren Emails) haben soll. Dazu ist dann auf Seiten...
• Forum: Netzwerke

  AW: OAuth2 erste Schritte

    Delphi
    by Phoenix, 2. Nov 2022
  Puh. Vorneweg: OAuth ist nicht ohne. Im IT-Security Bereich gibt es einen running gag: "Man kann es einfach haben, oder sicher. Such Dir eins aus."
  
  Der ganze "redirect-Tanz" über den default-Browser wird gemacht, damit a) der Benutzer seine Nutzerdaten (Benutzername, Passwort, 2FA Code etc.pp.) niemals an einen fremden Client (fremd aus Sicht des Identity Providers, im Falle von Azure also...