Aaron Parecki

#OAuth

OAuth

Aaron Parecki
Sat, Feb 4, 2017 11:35am -08:00

Hi, I'm Aaron Parecki. I write about OAuth here, and I give talks about OAuth 2.0. Below you'll find my recent posts about various OAuth-related things, including talks I'm giving. I've also written two community resources about OAuth:

OAuth 2.0 Simplified is a guide to OAuth 2.0 focused on writing clients that gives a clear overview of the spec at an introductory level.

In 2017, I published a longer version of this guide as a book, available on oauth.com as well as a print version. The book guides you through building an OAuth server, and covers many details that are not part of the spec. I published this book in conjunction with Okta.

Portland, Oregon

#oauth #oauth2

Sat, Feb 4, 2017 11:35am -08:00

Montreal (YUL) to Newark (EWR)

July 26, 2019 from 3:40pm to 5:13pm (-0400)

Air Canada Flight 7742

Newark (EWR) to Portland (PDX)

July 26, 2019 from 6:59pm (-0400) to 10:02pm (-0700)

United Flight 1572

Portland Intl in Portland

1 mention

#okta #oauth #ietf

permalink
Portland (PDX) to Newark (EWR)

July 22, 2019 from 6:00am (-0700) to 2:13pm (-0400)

United Flight 2248

Newark (EWR) to Montreal (YUL)

July 22, 2019 from 3:50pm to 5:19pm (-0400)

Air Canada Flight 7741

Pierre Elliott Trudeau Intl in Montreal

1 mention

#okta #oauth #ietf

permalink
IETF 105 Montreal

Jul

21

Jul

…

Jul

26

July 21-26, 2019
6 days

Hotel Fairmont The Queen Elizabeth

Montréal, Québec, CA

#okta #ietf #oauth

permalink
Adding Identity to OAuth XYZ

Aaron Parecki
Thu, Jul 18, 2019 4:27pm -05:00
The new draft spec at OAuth.xyz outlines a potential way to completely re-think OAuth from the ground up.

The XYZ spec, also nicknamed Transactional Authorization, effectively consolidates all of the different variations of OAuth that have evolved over the last decade, and plugs up a few security holes as well.

OAuth 2.0 has served us well over the last 10+ years, and has even been extensible enough to evolve to meet the new requirements of things like mobile apps and apps running on devices that don't have a browser or keyboard. It's hard to imagine that OAuth was originally created before the iPhone existed! That said, this extensibility has sometimes come at the cost of additional complexity, or at the cost of security. Many of the original assumptions that were made while designing OAuth 2.0 no longer apply, and the world of online security is very different today than it was 10 years ago.

The XYZ spec takes everything the industry has learned from OAuth 2.0 and OpenID Connect over the years and consolidates them into a uniform pattern, reducing reliance on less-secure communications channels, and building in flexibility in a consistent way.

If you're interested in the details of XYZ, the website oauth.xyz does a great job of laying out all the use cases with examples.

This post is not an overview of what XYZ is. Instead, what I'd like to talk about today is a suggestion for extending XYZ even further to encompass some additional use cases that have emerged, specifically about adding the user's identity information to the core protocol.

Identity has always been part of OAuth

OAuth was never intended to communicate information about the user who logged in to the app. This is a common point of confusion, usually wrapped up in the "authorization vs authentication" discussion. OAuth was originally created to give third party apps access to a user's account to read or write data at the API.

Naturally, many apps that want access to a user's resources also want to know who that user is. What ended up happening is most OAuth APIs added an endpoint that returns profile information about the user when requested with the access token. You can see this in common APIs like GitHub, Instagram, and Twitter. These were all developed independently, so they all work slightly differently and return data in slightly different formats.

GitHub
```
https://api.github.com/user
Authorization: Bearer XXXX
```
```
{
  "login": "aaronpk",
  "id": 1234,
  "node_id": "MDQ6VXNlcjE=",
  "avatar_url": "https://avatars3.githubusercontent.com/u/113001?s=460&v=4",
  "gravatar_id": "",
  "url": "https://api.github.com/users/aaronpk",
  ...
}
```
Instagram
```
https://api.instagram.com/v1/users/self/?access_token=XXXX
```
```
{
  "data": {
    "id": "1574083",
    "username": "aaronpk",
    "full_name": "Aaron Parecki",
    "profile_picture": "https://scontent-dfw5-2.cdninstagram.com/vp/a37666da4d6b670a849e7b77235e4d56/5DCD3710/t51.2885-19/s320x320/52837124_579812379154942_8897415153306304512_n.jpg?_nc_ht=scontent-dfw5-2.cdninstagram.com",
    "bio": "OAuth hacker",
    "website": "https://aaronparecki.com",
    "is_business": false,
    "counts": {
      "media": 1572,
      "follows": 285,
      "followed_by": 505
    }
  }
}
```
Twitter
```
https://api.twitter.com/1.1/account/verify_credentials.json
```
```
[
  {
    "id": 14447132,
    "id_str": "14447132",
    "name": "Aaron Parecki",
    "screen_name": "aaronpk",
    "location": "30,000 feet",
    ...
  }
]
```
OpenID Connect

OpenID Connect is built on top of OAuth 2.0 and provides a mechanism for applications to get the identity of the user that signs in. It does this in two ways.

The idea of returning profile information given an access token was standardized in OpenID Connect in the "UserInfo Endpoint". When a provider supports this endpoint, a client can send an access token and get back a representation of the authenticated end user.

OpenID Connect UserInfo Endpoint
```
https://authorization-server.com/userinfo
Authorization: Bearer XXXXX
```
```
{
  "sub": "https://aaronparecki.com/",
  "name": "Aaron Parecki",
  "email": "aaron@parecki.com",
  "preferred_username": "aaronpk",
  ...
}
```
This ends up looking very similar to the provider-specific endpoints that we looked at above.

OpenID Connect ID Tokens

The other way OpenID Connect deals with identity is by defining a new type of token, an "ID token". The ID token is defined as a JSON Web Token (JWT) that encodes the user's profile information. This ID token is then returned in response to an OpenID Connect request, either returned in the redirect URL using the implicit flow, or returned alongside the access token using the authorization code flow.

In the case of the implicit flow, the application that receives the ID token needs to validate the JWT signature and all the JWT claims, because otherwise anyone could drop an ID token into an application to be signed in. This is a standard part of the plain OpenID Connect workflow.

Applications that also need an access token in addition to the ID token should be using the authorization code flow to obtain the access token, otherwise they are at risk of the access token leaking.

So if an application is getting both an access token and ID token, the simplest way is to get both via the authorization code flow, so that both tokens end up being returned in the response to exchanging the authorization code at the token endpoint. This ends up looking like the below.
```
POST /token
Content-type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=XXXXXXXXX
&redirect_uri=https://example-app.com/redirect
&client_id={CLIENT_ID}
&client_secret={CLIENT_SECRET}
```
```
{
  "access_token": "SlBV32hkMG",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "2xMBxBtEp3",
  "id_token": "eyJhbGciOiJSUzI1..."
}
```
The interesting part about this is that in this case, the ID token validation step can be skipped completely, since validating it would provide no additional benefit. The application already knows it's talking to the right server, it knows the response is coming from that server, and the connection can't be tampered with since it will be made over HTTPS. This means the application can just extract the data it needs from the ID token and use it directly.

Identity in XYZ

Let's extend this idea of returning user profile information and bring it into the XYZ Transaction Response.

Transaction Request (Authorization Code Exchange)

The application takes the interact handle it got from the redirect and makes a POST request back to the authorization server to get an access token. (Described in Transaction Request.)
```
POST /authorize
Content-type: application/json

{
  "handle": "80UPWY2NM33OMUKMKSKU",
  "interact_handle": "CuD2MrpSXVKvvI6dN2awtNLx-HhZy46hJFDBicG4KoZaCmBofvqPxtm7CDMTsUFuvcmLwi_zUN70cCvalI6ENw"
}
```
Transaction Response (Access Token and User Identity)

In addition to the access token being returned, the user's identity information can also be returned in the same response.

The transaction response could include an OpenID Connect ID Token along with the access token, such as:
```
{
  "access_token": {
    "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
    "type": "bearer"
  },
  "user": {
    "id_token": "eyJhbGciOiJSUzI1..."
  }
}
```
This works great for applications that need to pass around the ID token to other backend components.

For simpler application architectures, they would benefit from skipping the step of extracting the user data out of a base64-encoded JSON string. When applications only need to know the user ID and maybe email address, and will then start their own session with the user's device, we could save a few steps and return the user's profile data directly:
```
{
  "access_token": {
    "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
    "type": "bearer"
  },
  "user": {
    "id": "5035678642",
    "name": "Aaron Parecki",
    "nickname": "aaronpk",
    "email": "aaron@parecki.com",
    "photo": "https://aaronparecki.com/images/profile.jpg",
    "zoneinfo": "America/Los_Angeles"
  }
}
```
Note that which values are returned would depend on the OAuth scopes requested, similar to OpenID Connect scopes.

This has the benefit of the system not needing to support a userinfo endpoint, which also means the userinfo endpoint can't be misused to attempt to create an authentication protocol.

This would cover the simple cases that we saw at the beginning of this post, which have been widely deployed in many systems that support OAuth 2.0, and wouldn't require that developers need to understand a new token type at all.

There should be a list of standard fields such as a unique ID, the user's name, email, and profile photo, and should also allow for providers to add their own custom user information into the response.

If we don't address this need in XYZ, we'll risk ending up in the same situation we're in with OAuth 2.0 where providers end up implementing their own snowflake APIs to let apps find the user's profile information.
Kansas City, Missouri

#oauth #xyz #txaz

Thu, Jul 18, 2019 4:27pm -05:00
Heather Downing https://twitter.com/quorralyne

Come to the @oktadev booth at #KCDC2019 to chat with fun and awesome people about #oauth #security and win stuff in it developer challenge! @briandemers @aaronpk @afitnerd @okta #Okta

Kansas City, Missouri

1 mention

#KCDC2019 #oauth #security #Okta

Wed, Jul 17, 2019 3:16pm +00:00 (liked on Wed, Jul 17, 2019 11:08am -05:00)
Heather Downing https://twitter.com/quorralyne

The king of candy bars... & #OAuth! @oktadev @aaronpk

Anaheim, California

1 mention

#OAuth

Fri, Jul 12, 2019 9:03pm +00:00 (liked on Fri, Jul 12, 2019 9:04pm -07:00)
privacy/security concerns · Issue #68 · plaid/link (web.archive.org)

London, England

#bank #security #oauth

Wed, Jun 19, 2019 11:32am +01:00
‘Sign In With Apple’ Earns Mixed Reactions From App Makers | WIRED (www.wired.com)

Portland, Oregon

#press #appleid #apple #oauth

Sat, Jun 15, 2019 11:44am -07:00
Last week I sat down with @nbarbettini to answer some questions about what's going on with the @OAuth_2 Implicit flow. #oauth 🎥➡ https://www.youtube.com/watch?v=CHzERullHe8

Portland, Oregon, USA

8 likes 4 reposts 2 mentions

#oauth #okta #oktadev

Mon, Jun 10, 2019 9:29am -07:00
I had fun with this one: 7 Ways an OAuth Access Token is like a Hotel Key Card

https://developer.okta.com/blog/2019/06/05/seven-ways-an-oauth-access-token-is-like-a-hotel-key-card

Portland, Oregon, USA

21 likes 9 reposts 2 replies 1 mention

#oauth

Wed, Jun 5, 2019 9:19am -07:00
Is 'Sign in with Apple' Marketing Spin or Privacy Magic? Experts Weigh In | Threatpost (threatpost.com)

Portland, Oregon

#oauth #appleid #press

Tue, Jun 4, 2019 3:21pm -07:00
Kurt Milne https://twitter.com/kurtmilne

Great write up on the new Identity solution Sign In With Apple. It's based on #Oauth and #Openidconnect Thank you @aaronpk

https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

Portland, Oregon

#Oauth #Openidconnect

Tue, Jun 4, 2019 9:44pm +00:00 (liked on Tue, Jun 4, 2019 2:56pm -07:00)
Let's Clarify some Misunderstandings around Sign In with Apple

Aaron Parecki
Tue, Jun 4, 2019 2:44pm -07:00

tl;dr This is a good move for users in the iOS ecosystem, and is primarily designed as an alternative for apps that currently use "Sign in with [Facebook/Twitter/Google]" to avoid leaking sensitive user info.

Yes, Apple is entering the OAuth ecosystem as a new identity provider. Turns out every iOS user already has an Apple account, so why not enable users to sign in with an account they already have?

Most of the time the way apps use OAuth providers is just to identify users. This is designed to be an alternative to using Facebook/Twitter/Google for that purpose.

This is distinctly different from the case where an app wants you to sign in with your Google account so that it can manage your calendar. Or sign in with Snapchat to apply a filter to your profile picture.

Those use cases are more along the lines of what OAuth was originally intended for: letting apps access your account without giving them your password.

Over the years, apps started to use OAuth to identify users because it's a quick way to find out and verify someone's Twitter/Facebook/etc account without having them type it in. This turned out to be bad for users' privacy:

Once an app knows your Twitter username or your email address, they can sell it to advertisers, or track your activity across other apps. Apple's approach provides a unique scrambled email address to the app, preventing this.

Now you may have heard people concerned by this clause from the new App Store Review Guidelines:

Sign In with Apple [...] will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year.

Sign In with Apple is a good thing for users! This means apps will no longer be able to force you to log in with your Facebook account to use them.

This does not mean that Apple is requiring every app to use Sign in with Apple. This does not mean that apps that want to manage your Google Calendar will have to also add Sign in with Apple.

Yes, this is a little additional work for app developers to support another OAuth provider, but is really not that different from supporting both Twitter and Facebook, or Snapchat and Instagram.

At the end of the day, the benefit of signing in to apps is to be able to save stuff to your account so you can restore it later, and to get email notifications.

"Sign In with Apple" provides apps with both those features without revealing any more information about you than necessary.

So yes, Sign In with Apple is a good thing for user privacy, and will be a better user experience overall.

Is Apple using their position as gatekeepers of the App Store to force adoption of "Sign In with Apple"?

Yes.

Is this a bad thing?

No.

Does this affect you if you don't use an iOS device?

No.

Does this benefit people who have an iOS device?

Yes.

Will we see other OAuth providers follow suit and start randomizing email addresses and user IDs returned to apps? I hope so!

Ironically, Facebook first started doing this a few years ago when they launched app-scoped user IDs.

Anyway, if you're curious about what this will look like, I wrote a sample app that uses Sign In with Apple so you can see how it works.

What the Heck is Sign In with Apple?

Sign In with Apple is based on OAuth 2.0 and OpenID Connect, and provides a privacy-friendly way for users to sign in to websites and apps

developer.okta.com

Portland, Oregon

145 likes 46 reposts 1 bookmark 27 replies 15 mentions

#appleid #oauth #wwdc19

Tue, Jun 4, 2019 2:44pm -07:00
Alright, if you are curious about "Sign In with Apple," I walk through exactly how it works and what it looks like in this post.

https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

#WWDC19 #OAuth #AppleID

Portland, Oregon, USA

98 likes 46 reposts 4 replies 5 mentions

#wwdc19 #oauth #appleid

Tue, Jun 4, 2019 12:43pm -07:00
Chris https://mrkapowski.com/

Aaron already has an example of Sign-in With Apple up and running, because of course he has 👍

Portland, Oregon

#apple #oauth #open-source #signin with apple

Tue, Jun 4, 2019 9:25am +01:00 (liked on Tue, Jun 4, 2019 6:16am -07:00)
Reading all these tweets of people freaking out about Apple requiring apps to use "Sign In with Apple" and feeling another "authentication is not authorization" rant coming. Lots of misunderstanding of sign-in vs accessing APIs. #WWDC19 #OAuth

Portland, Oregon, USA

7 likes 2 reposts 2 replies 1 mention

#wwdc19 #oauth

Mon, Jun 3, 2019 9:12pm -07:00
Initial test of the "Sign in with Apple" API:

• It's more or less based on OAuth + OIDC
• Their documentation is missing a lot of key info to use it right now, I had to guess at a lot of things
• The `sub` claim includes some sort of unique user identifier, not an email

Portland, Oregon, USA

74 likes 23 reposts 8 replies

#oauth

Mon, Jun 3, 2019 2:21pm -07:00
Well this is exciting. 🍎🔐 #AppleID #OAuth #WWDC2019 #WWDC

Portland, Oregon, USA

9 likes 1 repost 2 replies

#appleid #oauth #wwdc2019 #wwdc

Mon, Jun 3, 2019 1:38pm -07:00
at The Rec Room

Toronto, ON, Canada • Tue, May 28, 2019 11:00am

43.64111 -79.386763

Setting up for my talk today! #okta #oauth

Toronto, ON, Canada

78 Coins

#okta #oauth

Tue, May 28, 2019 11:00am -04:00
To anyone who thought partial redirect URL matching in @OAuth_2 is "good enough," read this thread. Complete Periscope account takeover just by viewing a tweet. https://hackerone.com/reports/110293 #oauth

Toronto, Ontario, CAN

13 likes 6 reposts 2 replies

#oauth

Mon, May 27, 2019 4:54pm -04:00