(Note that all times are local time, i.e., UTC+1.)

Please note that all unconference slots are placeholders that may be (and probably will be) changed during the unconference agenda finding.

Slides

Luca Arnaboldi, Hannes Tschofenig (ARM)

Slides

In this tutorial we would like to give you the know-how needed to formally verify your protocol or protocol extension using Tamarin. We will use OAuth-ACE as an example. To make the tutorial more entertaining you need to bring your laptop with you for the hands-on examples.

Johan Peeters (Johan Peeters BVBA)

Slides

In this workshop, we extend an idiomatic React browser-based app by adding capabilities to access protected backend resources. We go through design decisions and implementation. At each step, we

• weigh security guarantees against ease of implementation,

• ensure the code remains idiomatic, and,

• aim for a good UX.

The workshop’s main target audience are React developers, but this workshop is also useful for anyone confronting current (draft) standards and BCPs with coding practice. We will specifically address the following topics:

Cookies and security tokens are competing techniques for providing authentication context. When should one be favored over the other? The OAuth for browser-based apps BCP recommends the former for first-party apps and advises considering turning a third-party app into first-party by using a Backend-for-Frontend proxy: we discuss the pros and cons.

Until recently the implicit grant was recommended for browser-based apps. Due to concerns about the vulnerability of transporting security tokens in the URL, this advice has changed - the draft OAuth Security BCP now recommends authorization code grant with PKCE. Support for this grant amongst industrial-strength JavaScript client libraries is still patchy, but we show how to use it with oidc-client-js.

Logout turns out to be far trickier than at first sight. Do the tokens that were issued remain valid? What about the session with the authorization server? How can we optimize the logout experience?

A common strategy for storing tokens is to use browser Local or Session storage. However, code injected by an XSS attack into the same browser context will then be able to steal tokens. Unfortunately, even in a framework like React, it is still all too easy to leave the application vulnerable to XSS, as we will demonstrate. We also show how the attacker can be thwarted by keeping tokens in memory. Unfortunately, this also impacts on UX, as tokens do not survive a page reload.

Short token lifetimes require silent renew mechanisms for a fluent UX. Unfortunately, there is no silver bullet: implementations based on maintaining a session on the authorization server are flaky and refresh tokens are frowned upon in browser-based apps. We experiment with both, and explore their shortcomings.

I demonstrate that implementing the Principle of Least Privilege with respect to token scope is harder than necessary.

Apart from React, the main technical components for this workshop are

• AWS Lambda

• AWS API Gateway

• Auth0

• oidc-client-js

We will discuss alternatives for each and examine the forces that would push the web app design to another technology.

Participants should bring a laptop with an environment in which they feel comfortable writing React applications. An AWS account is not needed, but is useful for those who want to set up their own backend.

In order to speed up setup, participants can clone the git repo at https://github.com/softwarewolves/riders​ and run npm install. The objective of this workshop is to add the features of https://ride-sharing.ml​ to the cloned application.

(Note that the tutorials still continue in this time slot.)

In-person meeting of the OpenID FAPI Working Group.

We will have lunch at the campus.guest restaurant right next to the venue.

Pedram Hosseyni (SEC, University of Stuttgart)

Slides

Forced by regulations and industry demand, banks worldwide are working to open their customers' online banking accounts to third-party services via web based APIs. By using these so-called Open Banking APIs, third-party companies, such as FinTechs, are able to read information about and initiate payments from their users' bank accounts. Such access to financial data and resources needs to meet particularly high security requirements to protect customers.

One of the most promising standards in this segment is the OpenID Financial-grade API (FAPI), currently under development in an open process by the OpenID Foundation and backed by large industry partners. The FAPI is a profile of OAuth 2.0 designed for high-risk scenarios and aiming to be secure against very strong attackers. To achieve this level of security, the FAPI employs a range of mechanisms that have been developed to harden OAuth 2.0, such as Code and Token Binding (including mTLS and OAUTB), JWS Client Assertions, and Proof Key for Code Exchange.

At the Institute of Information Security of the University of Stuttgart, we performed a rigorous, systematic formal analysis of the security of the FAPI, based on an existing comprehensive model of the web infrastructure - the Web Infrastructure Model (WIM) proposed by Fett, Küsters, and Schmitz. To this end, we first developed a precise model of the FAPI in the WIM, including different profiles for read-only and read-write access, different flows, different types of clients, and different combinations of security features, capturing the complex interactions in a web-based environment. We then used our model of the FAPI to precisely define central security properties. In an attempt to prove these properties, we uncovered partly severe attacks, breaking authentication, authorization, and session integrity properties. We developed mitigations against these attacks and finally were able to formally prove the security of a fixed version of the FAPI.

Although financial applications are high-stakes environments, this work is the first to formally analyze and, importantly, verify an Open Banking security profile.

By itself, this analysis is an important contribution to the development of the FAPI since it helps to define exact security properties and attacker models, and to avoid severe security risks before the first implementations of the standard go live.

Of independent interest, we also uncover weaknesses in the aforementioned security mechanisms for hardening OAuth 2.0. We illustrate that these mechanisms do not necessarily achieve the security properties they have been designed for.

In the OSW 2019 talk, we will present the results our work, namely, the attack scenarios that we found during the analysis. Furthermore, we will present selected aspects of the model of the FAPI, together with our security definitions.

Torsten Lodderstedt, Daniel Fett (yes.com)

Slides

The OAuth working group is about to publish the OAuth 2.0 Security Best Current Best Practice (https://tools.ietf.org/html/draft-ietf-oauth-security-topics), which will elevate OAuth security to the next level. In this BCP, the implicit grant is deprecated, code flow shall be used with PKCE only, and tokens should be sender constrained to just mention a few of the new recommendations. Their development was driven by several factors, including experiences gathered in the field, security research results, the increased dynamics and sensitivity of the use cases OAuth is used protect, and technological changes. This session will present the new security recommendations in detail along with the underlying rationales.

Vittorio Bertocci (Auth0)

Slides

The core OAuth2 specification doesn't mandate any fixed format for access tokens, however many vendors issue their access tokens in JWT format. That makes it possible to handle the case in which authorization server and resource server are not co-located and/or are ran by different business entities, as it is the case in all identity as a service offerings.

Using a known format allows resource servers to efficiently validate incoming access tokens, however the lack of a common profile led to a babel of different ways if doing the same things, such as representing consented scopes, enforcing audience restrictions, publishing validation parameters reusing different discovery or metadata documents, and so on. This makes it hard to produce stable API protection SDKs that work across vendors on a given platform, to provide consistent and broadly applicable troubleshooting guidelines, and so on.

In this session we will discuss concrete usage of JWT in access tokens in various products/vendors, and how a JWT profile for access tokens could help identity as a service vendors and solutions to provide an interoperable reference that would make their and their customers life easier.

David Waite (Ping Identity)

Slides

A summary of the recommendations currently in draft-ietf-oauth-browser-based-apps, which aims to describe best current practices for browser-based applications ( aka javascript/single-page application/progressive web applications.)

This will have some light cross-referencing against draft-ietf-oauth-security-topics and RFC 8252 (OAuth 2.0 for Native Apps)“

Our conference dinner will take place at a very unique and exclusive venue: We will get together 144 m (472 feet) above ground on the Stuttgart TV Tower. This telecommunications tower is the very first of its kind and one of the most famous landmarks in Stuttgart. We will enjoy a sundowner and later have dinner over the roofs of Stuttgart.

Of course, you will also have the possibility to visit the public visitor platform on the roof.

Please note that we do not have a shuttle service. We recommend using public transport to get there. Use the S-Bahn trains S1, S2, or S3 from the underground train station right next to the conference venue to get to the station “Hauptbahnhof” (main station). There, you change to U-Bahn trains. You can take U7, U8, or U15 in direction Ruhbank (Fernsehturm)/Heumaden/Nellingen Ostfildern. (If you can catch a U15 train, then take it as the U15 takes a scenic route to the TV Tower.) No matter which subway you take, you should get off at “Fernsehturm”.

The address of the TV Tower is: Jahnstr. 120, 70597 Stuttgart.

Please be there on time to enjoy the sunset. The “golden hour” starts at 17:55 and sunset will commence at 18:35.

Neil Madden (ForgeRock)

Slides

Kubernetes adoption is rising rapidly, presenting new challenges for service to service and end user authorization. In this talk I will look at existing approaches to security in a Kubernetes environment and how OAuth can fit into that picture. The talk will describe some new deployment patterns using OAuth with mTLS to secure a “service mesh” deployment architecture, and to bootstrap a microservice cluster with zero need to store or distribute long-lived secrets.

Marco Squarcina (TU Wien)

Slides

In this talk we introduce WPSE, a browser-side security monitor for web protocols that we presented at USENIX Security '18. WPSE is designed to ensure compliance with the intended protocol flow, as well as confidentiality and integrity properties of messages. We formally prove that our approach is expressive enough to protect web applications from a wide range of protocol implementation bugs and web attacks. We discuss concrete examples of attacks which can be prevented by WPSE on OAuth 2.0 and SAML 2.0, including a novel attack on the Google implementation of SAML 2.0 which we discovered by formalizing the protocol specification in WPSE. Moreover, we use WPSE to carry out an extensive experimental evaluation of OAuth 2.0 in the wild. Out of 90 tested websites, we identify security flaws in 55 websites (61.1%), including new critical vulnerabilities introduced by tracking libraries such as Facebook Pixel, all of which fixable by WPSE. Finally, we show that WPSE works flawlessly on 83 websites (92.2%), with the 7 compatibility issues being caused by custom implementations deviating from the OAuth 2.0 specification, one of which introducing a critical vulnerability.

In this part of the workshop, all participants can make proposals for sessions to fill the unconference slots. Anybody who proposes a session will be given the opportunity to pitch their topic to the participants. A final schedule will then be decided upon by the participants.

The following proposals have been submitted upfront:

Dr. Michael B. Jones (Microsoft)

Much discussion of the merits of and problems with the OAuth Implicit flow has occurred since Torsten Lodderstedt’s article “Why you should stop using the OAuth implicit grant!” at https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926. I propose to lead a discussion on pros and cons of the Implicit flow in different contexts, recognizing that different uses of it have different security properties. For instance using bare, OAuth with response_type=token has different properties than OpenID Connect with response_type=id_token+token. The discussion should also cover the pros and cons of alternatives to the Implicit Flow in these contexts, such as the Code Flow, covering such topics as when refresh tokens are and are not appropriate and how to control whether they are issued. The result of the session should be a detailed set of notes summarizing the tradeoffs discussed to be used as input to further working group discussions and revisions of draft-ietf-oauth-security-topics. The discussion notes will record both points of consensus among the workshop participants and points of disagreement among the participants, evenhandedly summarizing both (or multiple) juxtaposed points of view, and the reasons for them.

Torsten Lodderstedt, Daniel Fett (yes.com)

When OAuth is used for Single-Page Applications (SPAs), these applications typically have to handle sensitive access tokens for authorizing their requests at resource servers. In the browser, these tokens are vulnerable to theft and misuse by attackers, e.g., through cross-site scripting attacks. Today's SPA implementations lack robust protections against such attacks.

In the light of recent discussions around updated best-practices for OAuth in SPAs, the OAuth working group proposes this session to find a common understanding of

• ways to protect access tokens in browsers,

• ways to limit the usefulness of tokens stolen from SPAs, e.g., through proof-of-possession mechanisms,

• ways to detect leakage of access tokens at resource servers, and

• architectures for SPAs that do not use access tokens in the frontend.

Johan Peeters (SecAppDev.org)

XSS remains a concern in modern browser-based web applications. It is therefore worrisome that security tokens are often placed in cleartext in local or session storage as any script injected in the app’s origin's browsing context can steal them. I therefore want to explore some techniques to prevent token theft:

• keeping tokens in memory, in a language scope inaccessible to injected scripts,
• using the sealer/unsealer pattern,
• sandboxing,
• token encryption.

The challenge with these techniques is to hang on to tokens across page reloads. We will discuss how this can be addressed by using a service worker or a minimal backend.

We will have lunch at the campus.guest restaurant right next to the venue.

We have reserved some (enough) tables at the Brauhaus Schönbuch in Stuttgart's city center (not the one in Böblingen). We recommend going there by public transport. You can take the S-Bahn trains S1, S2, or S3 from the underground train station next to the conference venue. Please take one of these trains to the station “Stadtmitte” (city center). From there, it is just a short walk to the Brauhaus.

The address is: Brauhaus Schönbuch, Bolzstr. 10, 70173 Stuttgart.

Please note that this dinner is not included in the conference fee and we will have á la carte dinner.

Amir Sharif, Roberto Carbone, Silvio Ranise, Giada Sciarreta (Fondazione Bruno Kessler, University of Genova)

🔗Website

OAuth 2.0 (hereafter OAuth) and OpenID Connect (hereafter OIDC) are among the most popular open standards for access delegation and SSO Login, respectively. The OAuth Working Group released “OAuth 2.0 for Native Apps”, the best current practice for native apps that suggests the use of the external browser and the authentication code flow with the PKCE support. More recently, the OpenID Foundation has made an effort to support developers by releasing AppAuth, a client SDK implementing the security and usability best practice. In this paper, we focus on the integration of OAuth and OIDC solutions offered by third-party Identity Management (IdM) providers in mobile native applications. We have checked the compatibility of the aforementioned best practice with the top IdM Providers using OAuth 2.0 and OIDC (based on the ones listed in the OAuth websites and the Alexa ranking). Our analysis reveals that:

• Many IdM Providers are still using their own SDKs, which often do not follow the best practices. Some of them (e.g., Yahoo) do not even provide any library.
•  The documentation they provide is not “compliant” with the best practices or it is not clear/misleading for the App developers.

As a consequence, by leveraging these “wrong” IdM mechanisms many mobile Apps are implemented in an insecure way. The situation is even worse in complex scenarios—which are more and more frequent with the advent of the API economy—where a single App interacts with many IdM Providers. Indeed, if this is the case, many SDKs must be imported in the App code, each of them with different documentation to follow. In addition, in this kind of scenarios, AppAuth cannot be easily adopted as well, because the available documentation is tailored to interact with a single IdM Provider. Therefore, App developers should develop their own methods: this can be an error-prone and time-consuming process especially for inexperienced developers.

To this end, in this paper, we propose a novel approach that guides developers through integration of third-party IdM providers within their native apps. It consists of an Android Studio Plugin (i) providing a user-friendly GUI to properly configure the application (ii) enforcing the usage of the best practice for native apps by integrating AppAuth and automatically generating the suitable code to handle it properly, and (iii) supporting the integration of multiple IdM Providers. The effectiveness of the proposed approach was verified by integrating several IdM Providers, such as OKTA, Auth0, Microsoft, and Google.

Dave Tonge (Moneyhub)

Slides

Over the last year the OpenID Foundation as worked to make the “decoupled” CIBA spec more generic. The spec was originally designed for use in the Mobile Network Operator space but there is now a strong interest to use it in financial applications. The spec is now an implementers draft and has already been adopted in Australia and the UK. In this talk I will go through the fundamentals of CIBA before diving into the privacy issues that arise from the use of shared identifiers between Clients and Authorisation Servers. I will also explore the security and privacy characteristics of using CIBA for subsequent interaction flows after an initial redirect based flow. Such multi-stage flows support a wide variety of use-cases and may well bring the right balance between security, privacy and usability. However the use of artefacts, such as ID Tokens, from a previous OAuth flow in a subsequent OAuth flow needs careful analysis, especially when such artefacts are being used in a manner in which they were not intended to be used. I will also explore the proprietary ways in which decoupled authorisation flows are currently being performed and the benefits that standards such as CIBA bring.

Luca Arnaboldi, Hannes Tschofenig (ARM)

Slides Paper

As our daily lives become ever more connected the need for security becomes more and more dire. This need is, however, in conflict with the way most IoT devices are designed because devices have limited computing power, memory and security mechanisms to defend against a range of attacks. The protocol designer must therefore take all these constraints in consideration when making design decisions on how to secure the IoT.

To bring authentication and authorization solutions to constrained IoT devices the IETF ACE working group was formed and profiled the OAuth protocol suite. Re-using already existing security protocols offers a lot of benefits since designing security protocols is not an easy task. In fact, it happens that protocols believed to be secure, even for years (e.g. the Needham-Schroeder authentication protocol), are found to be vulnerable with further investigation, sometimes using automated verification tools. Over the years several technologies for automated verification, such as Tamarin and Easycrypt}, have been developed. Given a protocol design and a set of security properties (e.g. secrecy and authentication) these tools can help to prove that the properties hold.

In this paper we use the formal analysis tool Tamarin to analyse the ACE-OAuth protocol and we illustrate how protocol designers can make use of this work for analysing their own extensions.

Jim Manico (Manicode Secure Coding Education)

Slides

Why are we talking about XSS in 2019? We're unfortunately still talking about client side script injection or Cross Site Scripting (XSS) in 2019 because it's painfully difficult to defend against XSS even to this day. This talk is a fundamental technology update on how developers build and secure web user interface code. We'll address new defensive strategies such as modern JavaScript framework defense in Angular, React and other frameworks. We'll also look at how CSP deployment has changed in the past 7 years illustrating the progressive use of content security which supports CSP v1, v2 and v3 concurrently. We will then look at advances in HTML sanitization on both the client and server side as well as focus on sanitizers and defensive libraries that have stood the test of time in terms of maintenance and security. We'll also look at interesting design topics such as how HTML injection is still critical even in the face of rigorous XSS defense and how HTTPOnly cookies are largely ineffective. This talk should help developers and security professionals alike build a focused and modern strategy to defend against XSS in modern applications.

We will have lunch at the campus.guest restaurant right next to the venue.

On Friday, we will again have some time for unconference sessions after lunch.

We will conclude the OSW in the closing remarks.

Picture TV Tower: pjt56 / Wikimedia Commons / CC-BY-3.0 & GDFL