Beyond OAuth: Transactional Authz

Beyond OAuth: Transactional Authz

Day/Session:Wednesday 1A

Convener:Justin Richer

Notes-taker(s): Tom Brown

Tags for the session - technology discussed/ideas considered:

oauth

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Session is related to recent article:

https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade

See Identiverse talk “What's Wrong with Oauth 2”

https://www.youtube.com/watch?v=OLwz7pIXOWQ&t=6s

Front channel unnecessarily puts a lot of stuff there, so it's a big target

Do not assume syntax and structure will be compatible with Oauth 2

Adding server side call to AS prior to redirect which addresses the following (where I = client app):

1. Who am I? e.g. name , logo (not redirect uri nor grant type. In fact grant type eliminated). This replaces static and dynamic registration
2. What do I want?
3. What can I do? e.g. redirect, display code, open app, do CIBA (replaces grant type)
4. (possibly) Who am I?

After first time, AS can say “next time you show up, instead of sending all this, just prove I gave you a handle”

Design goal of Oauth 2: make clients as stupid as possible

AS possibly boils down to one url with this approach

Client: I want to start an authorization transaction. Here's everything you need to know for what you want to do and I need user to approve this

AS tells client “I need you to do this and when you come back to me, present a transaction handle

client sends user to AS...here's where things are very different (but similar to UMA)

...just send transaction handle (today we call an auth code) with encapsulates everything

state param for CSRF needs to be sent before front channel

mixup problem discussion

only two possible results to send back to user: either the handle or failure. If the user clicks no, then still send handle

session fixation is why we need 2 handles

1. need to prove front channel closed properly
2. binding to back channel

front channel is optional because you might be able to supply enough info that user does not need to interact with AS

Implicit grant is gone!

No more response modes or types.

Downsides: More chatty, roundtrips. Mobile devs don't like to open more sockets.