Last week, I attended the 5th OAuth Security Workshop (OSW), a workshop where people working with OAuth can meet up and talk about anything related to OAuth security for 3-4 days.
This was my first time attending the OSW, so I thought I would share a few of my highlights and help raise awareness of the event.
Free Virtual Event
OSW is usually an in-person event, but for obvious reasons, this year it was a virtual event. This brought its own set of challenges, ranging from time zones (the conference started at 0500 for some people, 2100 for others), latency issues, feedback, background noise, and someone on a different call discussing how to enable MFA for their Atlassian users 🤷♂️. I think the agreement was that GoToMeeting was responsible for some of the technical issues we faced.
Personally, my participation was hindered due to work resuming on the road outside of my house. But, hey, at least I have a nice little patch of bricks to show for it!
This year’s OSW was also free, which meant that 300 people registered for a ticket, but unfortunately, as tends to happen with free events, not everyone turned up. I hope no one was unable to get a ticket because of this.
The conference started with a day of workshops, followed by a day of conference talks, and finished with two days of unconference talks where anyone could propose a topic, and the group gets to talk about it for an hour.
OAuth 2.0 for Browser-Based Apps
As part of the conference, Aaron Parecki gave an update on the OAuth 2.0 for Browser-Based Apps Best Current Practices (BCP) document he is working on, and we later spent 2 (and a half) unconference sessions discussing how to get the BCP out of draft.
Since the draft BCP was started, browsers have announced big changes to how they are going to treat 3rd party cookies. These changes are going to break many apps that rely on techniques such as silent refresh, check session, or host other apps within iframes. In fact, a Microsoft employee hosted an unconference session about the solution they are thinking about using in Outlook. They also mentioned that SharePoint is massively affected due to its “app within an app” approach.
As the workshop went on, the idea to resurrect online_access was proposed.
Building upon the offline_access scope found in OpenID Connect, online_access would authorize a refresh token to be created that is bound to the user’s session.
The client application would be allowed to get a new access token, as long as the user was still online.
I believe that the consensus was to propose this to the OpenID Foundation, as opposed to bringing both offline_access and online_access to the IETF.
We spent around three hours discussing this draft BCP, and Aaron did share a bit of heart-ache over not being able to get this BCP published due to lack of agreement of what the best-practices are.
Personally, I have found the BCP to be super useful even as a draft. It has helped my customers realize the dangers of using access tokens in the browser and caused many of them to move back to a server-side approach or create a backend for frontend.
I have found this BCP to be a lot less controversial than the OAuth for Native Apps BCP (which asks mobile developers to use a browser for user authentication), despite the initial messaging around the implicit flow.
App2App
App2app is a technique used by Open Banking mobile applications, where one app can initiate an authorization request which can be handled by another app on the same phone, rather than opening a web browser where the user may need to re-authenticate (app2web).
In the wild, I have seen this in use when transferring money between accounts across two different banks. In Bank A’s mobile app, I told them I wanted to transfer x amount from Bank B. Bank A then initiated an authorization request to Bank B, and my phone automatically switched to Bank B’s mobile app, which simply displayed a consent screen for that transaction. I consented, my phone brought me back to Bank A, and the money was transferred.
App2app uses reserved https schemes (aka “deep linking” or “universal links”), but it basically hijacks requests made to the target authorization server. The mobile app has become the authorization server. I don’t believe that this is 100% necessary, but rather a convenience mechanism where the app will always be able to make the authorization request; the same URL can open the app or the browser.
App2app is mandated by PSD2; however, there is currently no specification or consensus on how to do this securely within Android. From what I understood, this is reasonably secure in iOS; however, Android lacks the necessary checking for when the app is installed or a consistent user experience for moving to the app automatically vs. displaying a confusing choice to the end-user. This is especially difficult due to the user experience being different across versions of Android.
The workshop spent around 2 and a half hours discussing this, with employees from various banks joining in the discussion. The outcome is to investigate if a best practices or guidance document can be created and hosted within a standards body.
Interlude – The Social Event
Despite OSW 2020 being a virtual event, the organizers still arranged a social event. This didn’t involve booze, but rather fluffy animals with a video call with some llamas, alpaca, and camels 🦙.
I look forward to hearing from baby PKCE. I would like to propose a petting zoo for next year.
Financial-Grade API (FAPI)
Nat Sakimura gave an update on the progress of the FAPI v1 baseline and advanced profiles, which the OpenID Foundation is hoping to finalize this December. At the same time, they are hoping to release an implementors draft for FAPI v2, which aims to streamline the standard and include support for Rich Authorization Requests (RAR).
Hacking OAuth
Micah Silverman demonstrated the browser extension he created to simulate authorization code injection attacks and how PKCE defends against such attacks.
This involved a browser extension stealing the victim’s authorization code and stopping it from being swapped for tokens. The attacker then starts their own authorization request, injecting the stolen authorization code into the authorization response, and successfully logging in as the victim. This bypasses state validation, but as we know, PKCE or OpenID Connect’s nonce validation can prevent this attack.
You could argue that using a browser extension with permissions to modify requests is overkill (for example, you could just steal the session cookie); however, authorization code injection bypasses any traditional security methods (such as device fingerprinting) that the website may have implemented.
Micah did note that their extension required the same permissions as Okta’s implicit flow detector and that it was published on the browser extension store without any questions from Google or Mozilla.
There was some discussion around real-world usage of this attack. For instance, has it been used successfully in an attack or using something other than a browser extension? Mobile devices where malicious apps could steal an authorization code during redirection and leakage in HTTP requests and server logs were discussed.
OAuch
OAuch (pronounced oh-ouch, like someone gave you some disappointing news and then pinched you) is an upcoming tool for testing OAuth authorization servers, which aims to be the OAuth equivalent of services such as Qualys SSL Labs and Security Headers. This tool acts as a malicious client, trying to get your authorization server to issue it tokens. This tool is due to be released in September.
In their session, the author shared some statistics on the data they had gathered while testing their tool. For instance, a surprising percentage of implementations did not enforce the use of a client secret, despite the client being issued one. There was also an authorization server that issued access tokens valid for 27-years. But don’t worry, if that token expires, you still had a refresh token you could use.
Web ID
Web ID is a proposal made in the Web Incubator Community Group that brings identity into the browser, aiming to solve some of the problems that browsers are introducing with their upcoming 3rd party cookie changes.
To look at this spec was a brilliant idea of Aaron’s, where the workshop took a look at this proposal and discussed how it could help guide it in the right direction, especially since it borrows some technologies from OpenID connect.
At the moment, Web ID is a little too focussed on social logins and doesn’t consider the other use cases around federated login, but it does have some good ideas.
Near the end of the call, someone did manage to get the spec author to join the call, but as you would expect, that is when my internet died... I look forward to seeing the recordings.
Developers & OAuth
A session was proposed to discuss what the workshop can do to improve the accessibility of OAuth for developers.
The positive side of this discussion was the agreement to blog more. To get more people involved in OAuth, blog about the basics, how to get started, and how to solve specific use cases. I 100% agree with this, the more people writing about OAuth and explaining it in new ways, the more likely the reader is going to have that “Eureka!” moment and understand a concept. And the more people we can get discussing best practices, writing cheat sheets, and common security architectures, the better.
For the negative side of this discussion, I want to remind the workshop not to view developers as the enemy and to draw their eye to a quote from one of my articles – where I had to experience the cryptography community’s negativity towards the JOSE specification writers:
“Developers should not be trusted with security”
A toxic sentiment that seems to affect all communities: “x should not be trusted with y”, where y is a thing that they do for a living that x does not. Sure, we’ve seen some crazy security decisions from software developers, but we’ve seen the same mistakes and crazy code from IT pros, mathematicians, and cryptographers.
It’s also strange that the crypto community criticizes the spec writers for being developers, but developers criticize the spec writers for not being developers. It seems the specification authors cannot win.
Finger-pointing, patronizing, and shaming other communities does not help anyone.
Closing Thoughts
I’m glad I attended OSW2020. It’s a shame that the event had to be virtual, but there’s nothing to be done about that. It took a while for the audience participation to properly kick in, but when it did, it certainly made attendance worthwhile.
online_access or something like Web ID may well be what bails out many of my customers who have web apps like SharePoint, where a single page hosts many other apps within iframes, a technique that will stop working in the coming years.
I hope to attend in person, next year in Trondheim.