API Days Berlin 2017 Presentation

On November 8, I gave a presentation in Berlin, Germany, at “APIDays Berlin 2017: Banking APIs and PSD2 — The finish line for PSD2 and Open Banking.”

Here are the slides from that presentation.

Several questions came up during the session.

Q.1 What is the purpose of protecting the code and state?

A.1 In RFC6749, the authorization server returns the code and state in the authorization response. To protect this response against modification, they must be signed. A detached signature is implemented by putting hashes of these parameter values in the payload, creating a signature, and sending these together with the response. This detached signature is called an ID Token. The name is not particularly good, but it cannot be helped.

Q.2 Why is it necessary to protect the state? Is it not sufficient to compare the received state with the one that was sent?

A.2 An attacker can replace the code and ID Token together within their own browser session while continuing to use their own state. In that case, comparing the state will not detect the attack. It is therefore necessary to bind and sign the state and code in the ID Token and attach it as a detached signature over the response.

Q.3 The application I built uses the Resource Owner Password Credentials Grant because I could not persuade the business side. What should I actually have used?

A.3 The Resource Owner Password Credentials Grant is deprecated. It should not be used. It may still be tolerable if the authorization server and client belong to the same security domain, but it should not be used because it facilitates phishing. If you control the authorization server, you should be able to exercise complete control over the look and feel of the In-App browser tab [RFC8252] and implement the same user interface as with Resource Owner Password Credentials. By doing so, you will be able to maintain 2 independent security contexts. This should also enable you to meet the EBA requirements. If the authorization server belongs to a third party, using Resource Owner Password Credentials amounts to conducting “well-intentioned phishing,” and it will stop working the moment the authorization server introduces phishing-resistant credentials.