The Direct Mode is a proposal for extending the reach of Open Banking APIs with payments as primary target. The concept builds on a secure bootstrap process using OAuth2. After the bootstrap, users can pay with dedicated payment credentials including EMV cards. The Direct Mode is a lightweight alternative to progress-constraining extension-schemes like Embedded SCA.

The End-to-End Encryption Task Force of the Financial Data Exchange (FDX) Security & Authentication Working Group is chartered to define a proposed specification for sharing certain sensitive customer information within the financial ecosystem. During the past few months, the members of the E2E Encryption Task Force have defined an end-to-end encryption design specification for adoption as part of the FDX standard. This talk will cover the challenges in defining an end to end encryption strategy, and the proposed solutions

Witness a practical demo of an authorization code injection attack! You'll see how our Hax0r D00d assumes the identity of the R00b D00d.

Spoiler alert: Using the PKCE extension with a confidential client thwarts this attack. You'll see this in action too.

An application development pattern we've seen is one of combined front- and back-end authentication, e.g. for server-side rendering of a single-page app. When the implicit flow was a recommended and feasible solution, applications would use the authorization code flow to authenticate the back-end, and then use the implicit flow to authenticate the front-end silently. This resulted in a single auth prompt for users, a desired user experience.

As privacy-conscious features in browsers block the use of 3rd party cookies, this pattern is no longer supported, and popular opinion on the implicit flow is turning. Applications could do two separate code flows to authenticate the front- and back-end separately, but this set of redirects is unappealing for users. Instead, we propose an extension to the confidential client authorization code flow to allow the back-end to request a new authorization code suitable for redemption on the front-end.

This is work driven by Hirsch Singhal of Azure Active Directory, who will also participate. See the proposal at https://github.com/hpsin/HybridCodeFlowProposal/blob/master/Hybrid-App-OAuth.md .

Let's discuss building OAuth applications in the browser-based app environment, and what are the particular considerations that need mentioning.

Specifically, we'll collect feedback on the parts of the OAuth 2.0 for Browser-Based Apps draft that still need work. We'll discuss the architecture where the OAuth flow is performed in a Web Worker, isolating the tokens from the main browser window scope.

Following on from the app2app talk, let's talk more about the security model, recommendations / anti patterns, alternative implementations, and whether anything should be standardised,.

The OAuth 2.0 authorization framework [RFC6749] defines the parameter "scope" that allows OAuth clients to specify the requested scope, i.e., the permission, of an access token. This mechanism is sufficient to implement static scenarios and coarse-grained authorization requests, such as "give me read access to the resource owner's profile" but it is not sufficient to specify fine-grained authorization requirements, such as "please let me make a payment with the amount of 45 Euros" or "please give me read access to folder A and write access to file X".

This session is about Rich Authorization Requests (RAR), a new OAuth draft allowing clients to specify their fine-grained authorization requirements using the expressiveness of JSON data structures.

https://tools.ietf.org/html/draft-ietf-oauth-rar-01

This session introduces OAuth 2.0 Pushed Authorization Requests (PAR).

https://tools.ietf.org/html/draft-ietf-oauth-par-02

PAR is an OAuth extensions allowing clients to send the authorization request payload to the AS in a backend request instead of going through the front channel.

This has many advantages in comparison to traditional authorization requests:

- there is only a reference to the request object sent through the browser, making the mechanisms robust and secure while allowing the client to pass virtually unlimited payloads

- the client is authenticated and authorized before the user interaction starts, which improves security and usability

WebID is an early exploration of ways that Browsers can help users of the Web make safer decisions while logging in on websites with identity providers with high-level purpose-specific APIs.

https://github.com/WICG/WebID

Let's read through this proposal together and discuss how it relates to OAuth!

I just heard about this proposal recently and have only done a cursory reading, so I am by no means an expert on it, so this won't be a presentation so much as a joint learning experience!

Developers mostly do not read the OAuth specs, instead, they tend to look up insecure solutions in StackOverflow, etc.

I would like to discuss/collect how we can better reach the developers regarding implementing OAuth in a secure way. One idea for example could be to add an OWASP cheat sheet for OAuth 2 & OpenID Connect but it would be great to have lots of more ideas.

In this session, we'll explore the DPoP draft together.