Hi, I am Nat Sakimura. It is an honor to be able to present in front of the distinguished audience, and I am very thankful to the APIDays committee for letting it happen. I am a Research Fellow at Nomura Research Institute, Chairman of the Board of the OpenID Foundation, and Chair of the Financial API WG among other things. If you are in API security field, you probably heard about me because I am an author of OpenID Connect, JSON Web Token, JSON Web Signature, OAuth PKCE, etc. OK. Now, here is the first Proposition to be discussed today:
The answer is of course “NO”. Like Mark O’Neill of Gartner spoke yesterday, Building blocks needs to be combined correctly. Just saying #oauth does not do the job.
It is abundantly clear even from the title of RFC6749. It is “The OAuth 2.0 Authorization Framework”. It is a framework, not a concrete protocol specification,
So that it can span across various service environemnts. Here, I have depicted it in two dimentions. Horizontal axis is the degree of environment control and the vertical is the stake that the API is protecting. As a framework, it needed to cover all quadrants, and OAuth 2.0 Framework does so.
Which is all good, but it also means that you need to profile it to suit the specific situations. For example, for the closed circuit factory application usecase, the security could be maintained by the close control of the environment so you may not need to do much on the application layer like OAuth. It probably is also ok to use a naïve implementation choice like bearer token in may social sharing scenarios as the stake is low though the environment is far from being controlled. But that does not apply for a higher stake scenario such as online banking. You got to be darn careful in such cases. 銀行のOpen APIは、環境制御レベルの低いインターネット上で、価値が中～高の対象を取り扱うため、
And, to create such profile for Financial APIs, there are multiple factors that you actually have to take care of, many of which are often ignored and results in awfully insecure OAuth 2.0 implementations.
One of the common mistake is not following the OAuth’s security assumptions. For example, OAuth’s primary security assumption is that there is only 1 Authz Server per client. But that assumption is violated in many cases. For example, a Personal Finance Client will necessarily have multiple Authz Svs. In that kind of cases, you have to make sure to have a proper virtual separation, that is, having different redirect endpoints for each authorization server to avoid Authz server mix-up attack etc. It has to be like the picture on your left. Unfortunately, in many implementations, they get lazy and re-use the same redirection endpoint like the figure on your right, which is a big mistake.
And there are bunch of other issues to be resolved. Message Authn probl.
Financial APIセキュリティの現状について @ OpenID BizDay 10
Nomura Research Institute
• OpenID® は、 OpenID Foundation の登録商標です。
• *Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks.
米国OpenID Foundation 理事長