1:48pm

Aaron Parecki

#oauth

  • 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
    #oauth #oauth2
  • Google Docs phishing attack underscores OAuth security risks | ITworld (www.itworld.com)
    Portland, Oregon
    #oauth #press #inthewild

  • Day 59: Updated the Logo on IndieAuth.com's GitHub Login #100DaysOfIndieWeb

    Fri, Feb 17, 2017 8:56pm -08:00

    This evening, Tantek pointed out to me that while he was logging in to the wiki via IndieAuth.com for the first time on a new computer, there was something a little strange about the IndieAuth.com flow...

    Here's the screenshot of what he saw:

    I definitely agree this is somewhat disconcerting. So here's what I did to fix it.

    I first didn't realize that if you don't upload an application icon to GitHub when you create an application, it will use the profile photo of the user who created the application for the OAuth screen. I guess I should have remembered this, since I included a screenshot of GitHub's OAuth screen in the User Interface chapter of my OAuth book.

    I first assumed that I would have to transfer the ownership the application to an organization that has the logo I wanted to appear. I did that, and encountered a strange message on GitHub when I moved the application from my aaronpk account to the new IndieAuth organization.

    I have absolutely no idea what this message is trying to tell me. I reported my confusion to a friend who works at GitHub, so we'll see if they fix that soon.

    Afterwards, I then realized I didn't in fact need to transfer the ownership of the application, and could just upload an application icon instead. Much easier!

    So I uploaded a logo to GitHub, and also changed the name of the application from "IndieAuth" to "IndieAuth.com". This is part of my long-standing regret of naming this service IndieAuth, since it's also now a protocol that anyone can implement and is not actually tied to me running this service. I wish I could change the name of this service, but too many people are referencing indieauth.com in their code now, especially since it's one of the few remaining OpenID providers left.

    I tried adding a description of the application, hoping that it would appear on the GitHub OAuth screen, but sadly it did not! (I also reported that to GitHub, so I'll find out soon if it's a bug or if I'm misunderstanding their help text.)

    After all that, the end result is that now when you sign in to something using IndieAuth.com with your GitHub account for the first time, you no longer see my face!

    Hopefully this is much less shocking for people who are using this! I'm not a huge fan of the logo, although I do like the "clever" shape of the "A" with the negative space forming the "i". Maybe I just need to drop the outline. Perhaps that will be a future #100days project!

    Portland, Oregon
    1 like 1 mention
    #100daysofindieweb #indieauth.com #oauth
  • When I see an access token that begins with "eyJ", I base64-decode the middle part to see what data they store in it. #oauth #jwt #security
    Portland, Oregon, USA
    14 likes 3 reposts 1 reply
    #oauth #jwt #security
  • Oakland (OAK) to Portland (PDX)
    to
    Alaska Flight 2644
    Portland, Oregon
    #oauth #consulting
    permalink

  • Day 35: Handling Redirects of Updated Blog Posts #100DaysOfIndieWeb

    Tue, Jan 24, 2017 9:26pm -08:00

    My blog post from 2012 titled "OAuth 2 Simplified" is my most popular article on my website by an order of magnitude. It is referenced by over 400 repositories on GitHub, and ranks very high in searches about OAuth. I still get tweets over four years later from people who discover it for the first time and are very appreciative of finding a succinct summary of the protocol. I wrote it in 2012, when OAuth 2.0 was still relatively new, and it was based on the best practices at the time. 

    Today I was reviewing the post, and realized that there were quite a few places where the industry standards have changed either in the terminology or in the best practices. I decided that I wanted to publish a new version of the post updated for 2017 based on what has happened in the industry over the last few years. I didn't feel comfortable updating the post at its current URL, from 2012, since that seemed like it would be rewriting history. But at the same time, I don't want to make people landing on that post from a web search or link from a GitHub repository to have to click another time to see the latest version of the post.

    I decided on an interesting compromise. I took the existing post, rewrote parts of it, and published it at a new URL: https://aaronparecki.com/oauth-2-simplified/

    I then took the old post, copied it verbatim, and published it at a new URL dated the same date as the old post: https://aaronparecki.com/2012/07/29/7/oauth2-simplified

    The final step was creating a redirect from the post's old URL https://aaronparecki.com/2012/07/29/2/oauth2-simplified (note the "2" vs the "7") to the new URL that has no date component. (This is the part that required a new bit of code for p3k, in order to handle redirects from posts that would have otherwise matched a post permalink.)

    My plan going forward is to always keep the version at https://aaronparecki.com/oauth-2-simplified/ up to date, and to keep snapshots of older versions at date-based permalinks at the time when I publish an updated version. I link to the previous versions of the post at the bottom of the primary post. (Manually for now, until I decide this is an important enough feature to automate). 

    I think this strike the right balance between providing visitors with the most current information with the least amount of effort, while still preserving the history of the older versions.

    Oakland, California
    1 mention
    #100daysofindieweb #oauth
  • Portland (PDX) to Oakland (OAK)
    to
    Alaska Flight 2563
    Portland, Oregon
    #oauth #consulting
    permalink
  • @jaredhanson oh funny! I got token_endpoint from OpenID Connect: http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata I will take a look at the OAuth 2 link rels tho.
    Portland, Oregon, USA
    #oauth2 #webmention #oauth
  • Support Universal Links (developer.apple.com)
    Cannon Beach, Oregon
    #oauth #apps #ios
  • a little light beach reading: "OAuth 2.0 for Native Apps" #oauth
    Cannon Beach, Oregon, USA
    6 likes 2 replies
    #oauth
  • @glenndayton Thanks! Glad you like it! I just published a more thorough guide on https://oauth.com you might want to look at too!
    Portland, Oregon, USA
    2 replies
    #oauth
  • Las Vegas (LAS) to Portland (PDX)
    to
    Alaska Flight 629
    Portland, Oregon
    #oauth #okta #oktane #oktane16
    permalink
  • Happy to announce https://oauth.com - a guide to building OAuth 2.0 servers! #oktane16
    Las Vegas, Nevada, USA
    33 likes 22 reposts 2 replies 3 mentions
    #oktane16 #oauth #oauth2
  • Oktane 2016
    Aug
    29
    Aug
    30
    Aug
    31
    August 29, 2016 at 5:30pm UTC-8
    Aria Resort
    Las Vegas, NV
    #okta #oktane #oauth #oktane16
    permalink
  • Just launched a big reorganization of https://oauth.net which should make it easier to find things! 🔒 #oauth2 #oktane16
    Las Vegas, Nevada, USA
    7 likes 2 reposts
    #oauth2 #oktane16 #oauth
  • Portland (PDX) to Seattle (SEA)
    to
    Alaska Flight 2210
    Seattle (SEA) to Las Vegas (LAS)
    to
    Alaska Flight 604
    Portland, Oregon
    #oauth #okta #oktane #oktane16
    permalink
  • In reading this over, I noticed a subtle difference from the Facebook and Google implementations, and I'm wondering if this was intentional or not. Section 3.1 says "The authorization server prompts the end-user to authorize the client's request by entering the end-user code provided by the client." The introduction has even more explicitly different wording: "(D) ... If the end-user agrees to the client's access request, the end-user enters the end-user code provided by the client." However this is different from Facebook and Google's implementations, which work as follows: - Device shows the verification URI and code to the user - The user visits the URL and is prompted to sign in to the service (Google has the extra step of then choosing which Youtube account to use) - The user is then prompted to enter the device code - After entering the device code, the authorization prompt is displayed In reading this draft, the implication is that the act of entering the code also is the authorization. The problem is that the server won't know things like the scope or application name until after the code is entered, so it can't properly show an authorization prompt. I think this needs to be reworded to separate entering the code from showing the authorization prompt. I believe it is only a wording change. Maybe something more like: 3.1 "The authorization server prompts the end-user to enter the end-user code provided by the client, after which it prompts the end-user to authorize the client's request." and in the introduction: 1. (D) "The authorization server authenticates the end-user (via the user-agent) and prompts the end-user to enter the end-user code provided by the client. The authorization server validates the end-user code and prompts the end-user to grant the client's access request."
    Portland, Oregon, USA
    #oauth
  • Implementing OAuth 2.0 access tokens | NimbusDS Blog (nimbusds.com)
    #oauth2 #oauth
  • Well this is progress... an in-app browser that shows the address bar and shares system cookies
    Portland, Oregon, USA
    3 likes 1 repost
    #ios9 #oauth #oauth2 #ios
  • Changes in iOS 9.0 (developer.apple.com)
    SFSafariViewController can be used to display web content within your app. It shares cookies and other website data with Safari, and has many of Safari's great features, such as Safari AutoFill and Safari Reader. Unlike Safari itself, the SFSafariViewController UI is tailored for displaying a single page, featuring a Done button that takes users back to where they were in your app.
    #oauth #oauth2 #ios #ios9