Aaron Parecki

Sunday, June 11, 2017

• 
• 

  11:17pm

  Asleep

  6:23am

  Awake

  7h 06m

  Slept

  22m

  Awake for

  

  Portland, Oregon, USA

  Sun, Jun 11, 2017 6:23am -07:00
• Sebastian Kippe https://updates.kip.pe/profile/basti

  I'll be in PDX for two weeks from next Thursday on. Visiting friends, going camping, attending IndieWebSummit, and hitting the taprooms. \o/

  Portland, Oregon

  Sat, Jun 10, 2017 9:57pm +00:00 (liked on Sun, Jun 11, 2017 6:56am -07:00)
• 

  at Dollar Tree

  Portland, Oregon • Sun, June 11, 2017 2:35pm

  45.53616 -122.619461

  On an expedition to find an FM radio

  Portland, Oregon

  1 reply 1 Coin

  Sun, Jun 11, 2017 2:35pm -07:00
• https://mailarchive.ietf.org/arch/msg/oauth/h0ivzMZBHjXGi6HqcB0LYdR4skw

  OAuth Working Group
  

  I've seen this done a few ways:
  
  • The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device.
  • I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal.
  • The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.

  Portland, Oregon, USA

  Sun, Jun 11, 2017 8:59pm -07:00 #oauth #oauth2