Beyond OAuth: Transactional Authz

From IIW
Jump to: navigation, search

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.