That's basically what the Device Flow is, except manual. You ... • Aaron Parecki

Anders Pitman https://twitter.com/anderspitman • Jan 21
Why not open a new tab for interacting with the auth server, while simultaneously opening a back channel request in the original session? Once the user has authenticated/authorized from the new tab, the back channel request would resolve. 2/

That's basically what the Device Flow is, except manual. You certainly could do that. I suspect it would be fragile at best though, and wouldn't work well in mobile browsers.

Portland, Oregon, USA

Tue, Jan 21, 2020 11:04am -08:00

4 replies
Have you written a response to this? Let me know the URL:
- Aaron Parecki twitter.com/aaronpk
  
  by "fragile" I mean things like vulnerable to popup blockers, popups are bad UX on mobile browsers, etc.
  
  Tue, Jan 21, 2020 11:59pm +00:00 (via brid-gy.appspot.com)
- Aaron Parecki twitter.com/aaronpk
  
  The spec has a way the AS can provide a URL that the user should visit to the app. So the app has to get the user to that URL somehow, doesn't matter how, and doesn't matter what that URL is.
  
  Tue, Jan 21, 2020 11:58pm +00:00 (via brid-gy.appspot.com)
- Anders Pitman twitter.com/anderspitman
  
  That's interesting. After a quick review, it does seem pretty similar. Why the timeout polling instead of long polling? Does the spec dictate what back-channel you send the user to?
  
  Tue, Jan 21, 2020 11:01pm +00:00 (via brid-gy.appspot.com)
- Anders Pitman twitter.com/anderspitman
  
  What do you think would be fragile about my approach? Giving the client control over the random value?
  
  Tue, Jan 21, 2020 10:59pm +00:00 (via brid-gy.appspot.com)

Posted in /replies using quill.p3k.io