Here is the slide I used for APIDays Berlin 2017: Banking APIs and PSD2 — The finish line for PSD2 and Open Banking.
A couple of questions came around, which I did not do a really good job of answering. Here are clearer answers:
Q.1 What does protecting ‘code' and ‘state' mean?
A.1 In RFC6749, what is being returned from the authorization endpoint is the ‘code’ and ‘state’. To protect the authorization response from being tampered, you need to put a signature on it. Detached signature works by including the hash of these values in the payload to be signed over and sending it together, which we call ‘ID Token’. Not a good name, but we have to live with it.
Q.2 Why does the ‘state' needs to be protected? The state can be compared to the one sent.
A.3 The attacker can swap code and ID Token at the same time with the victim’s while continue using the attacker’s state and the browser session. The state and the code need to be bound together within a signed ID Token as a detached signature to the authorization response.
Q.3 My app is using Resource Owner Password Credentials Grant as we could not persuade the business. What should be used?
A.3 Resource Owner Password Credentials Grant is deprecated. It should not be used. If the Authorization server and the client are in the security domain, it is less serious, but we really should not. If you are controlling the authorization server, then you should be able to control the look and feel of the In-App browser tab [RFC8252] so the user experience is the same with the case of the Resource Owner Password Credentials and you now have two separate security contexts. If the authorization server is a third party, then what you are doing is a benevolent phishing and as soon as the server introduces phishing resistant credential, it will break.