PacktPub sent me another book for review after the quite good Learning Cython Programming (which I reccommend!), this time the book is OAuth 2.0 Identity and Access Management Patterns (Packt). I’m afraid to say I’m not incredibly impressed.
The book is not bad; the content is there and it can be useful, just I don’t know if the price attached to it, especially from Amazon or for the print edition is worth it. From one point of view, OAuth 2 itself is quite simple in its design, intentionally, as the previous implementation was obviously overcomplicated; on the other, the book sticks strictly to the protocol itself rather than describing ways to integrate it with your application.
One of the weakest points of the book is that it sticks strictly to the terminology used by the standard. While terminology is important, it would be nice to have a more “plain English” definition of what’s going on, and an explanation of said terms. Even things like “secure storage” are not obvious (secure to whom?).
Books like this to me are good if after reading it I have fewer questions than when I started. I did choose to review this one because I have had bad experience while trying to implement OAuth before – and the messy hybrid that was the first version of Facebook Connect – and I wanted to know what the current state of the art is in the authentication department. But the book did not make it any clearer to me.
There’s lots of hand-waving, too. For instance the state parameter that is passed on during requests is told «can be used for defending against man in the middle attacks» — but there is no explanation on how this works; sure it’s passed unmodified back to the caller, but what are the semantics? Similar to XSRF tokens? If there is such an attack, what stops Eve from using the same state value? I’m sure there are answers and best practices, but the book does not help me there.
There are also some references that while factually true, are rendered in such a way to be ambiguous and misleading. When explaining the advantages of OAuth 2 over previous authentication systems, for example, it gets compared to HTTP Basic Auth complaining:
The drawback here is that, in this type of authentication, the user, alongside his username, enters and sends his password over the wire as well.
While this is true, nobody in their sane mind would use basic authentication nowadays; indeed anybody who wants to use HTTP-level authentication would use digest auth which does not suffer from the just-listed problem. Sure it has other issues, but that’s still the case.
The book will eventually proceed to explain what the advantage of OAuth 2 over user/password authentication is (fine-grained access control to resources hosted at a third-party service), but even just pointing that out right away would have been an improvement. Indeed here the problem is not that username and password are passed over the wire (they almost always are, at some point), but rather than you don’t have to provide your (say) Facebook password to (say) Duolingo for it to be able to find your friends already on the system. This is a definitive win over user/password authentication, but is not really made clear. Not that OAuth was the first implementation of a token-based authentication: after all Kerberos is a technology of the 80s.
The calls to security measures are also vague, ranging from security through obscurity by suggesting to «perform code analysis» to make reverse engineering harder (what?), or to encrypt a whole SQLite database to prevent SQL injection attacks. Oh and there are no other apps beside JavaScript “client apps” and mobile applications. Maybe the desktop is already dead? I don’t think so.
I’m sorry if I sound harsh, but the author definitely knows the topic, so I would have hoped for more, especially for the not-so-cheap price the book is sold at. Toward the end of the book, lots of pages are “wasted” by XML dumps when trying to explain how to make use of SAML 2.0 — without explaining what it is or why we should care (not that online I could find a good answer to this).
At any rate if you’re struggling with OAuth 2, the book is not bad, but unless you really want to spend on books, this one is not for you.
While this is true, nobody in their sane mind would use basic authentication nowadays; indeed anybody who wants to use HTTP-level authentication would use digest auth which does not suffer from the just-listed problem.
I don’t see much difference between using HTTP Basic and form input field. And using them over HTTPS is comparable to using SASL PLAIN auth over TLS.
The main win, which you say they mentioned too late in the book, really is the simple approach to scoping; as is the distinction between refresh and access tokens.
Did the author discuss OpenID Connect and userinfo shipped in JWTs? That’s a pretty neat trick, actually. I also like the OAuth SASL method — shame there hasn’t been more adoption in email/calendar/contacts clients apart from the usual hardcoded providers.