On why OAuth 2.0 is weak

    Recently, I have been reading up a lot on OAuth 2.0, particularly on the token formats. OAuth 2.0 supports quite a few tokens - Authorization token, Refresh token, and Access Token (apart from Authorization Grant). I think that at a high-level this is a very good approach. It creates flexibility for functional entities. However, from an interoperability perspective, the standard should (MUST, actually) focus not just on the protocol, but on the structure and semantics of those tokens. Unfortunately, OAuth 2.0 specification fails here.
    Take the Access token (which needs to be interoperable between the Authorization Server and the Resource Server). The spec clearly states that how the RS validates the access token is out of scope - what?? Imagine a situation where I am building a RS - I need to know how to validate this token, don't I need to? May be Facebook gives out one type of token and Google does another - what am I to do?
    The text from the spec says "...The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification, but generally involve an interaction or coordination between the resource server and the authorization server." Well, what is the nature of that interaction? Again left undefined.
    I understand that token is an abstract concept. However, if you look at SAML for example, tokens have been clearly defined - particularly the signature mechanism. A token in SAML terms is an assertion containing a particular statement, and carrying a signature as per SAML spec. Now, I again understand that you can use SAML assertions as tokens in OAuth, but the point is that it is not explicitly required - meaning that you can expect a SAML assertion as token, or may be some other.
    Am I mistaken?

Disappearing IdPs!

Recently, I was passed this link Disappearing IdPs. It is quite an interesting news - a popular IdP folding! The danger that the article points out is quite real - the frustration to the users is enormous.


Though I do not quite see this danger becoming prevalent or common place (like traffic accidents, for example) - the probability of it happening is uncomfortably high - there is no guarantee that a particular web site will not fold, for ever. As the article points out, it may not happen with Google, or any similar providers. However, there could be other dangers lurking - the credentials at the IdP could be stolen, the provider could be down for prolonged periods of time (DoS, for ex.), the local government could decide to block the IdP for whatever reason (it can certainly happen for Google -given it is so big).


This danger needs a solution. One thing I could think of is - federation. All service providers MUST use federation, in stead of plain SSO. The local user ID could still be the user ID from the IdP (assuming there are not going to be conflicts across domains - email IDs can prevent such conflicts). There must be a (compulsory) step that allows the user to create a local identity after they log in with their IdP credentials for the very first time. The support for these credentials (like password self-reset, for example) can follow the standard paradigms (may be security questions?! see my earlier post!). But the key is that the user can now login with the local credentials as well. This can be used in such emergency situations like when the IdP is not available.


There could be other thoughts. Will certainly like to hear them.

Agile methodologies - good or bad?

This is another of my pet topics - agile methodologies. You may wonder, why am I cribbing about this now - this is not new any more. But the fact is that many organizations are getting into Agile, still. See, it is a tectonic shift from, well, water-fall. So, people are not sure if it applies to them, if so in what way. May be they are scared of 'new', may be they are worried about learning new tricks, or may be they just do not see the point!

I do not exactly belong to that last category, but I am pretty close. Here, I want to explain how I differ.

Let me be clear up front, I am no fan of big, fat water-fall. I think that it is clearly old school. We need a more nimble, smarter way of developing things ('things', not just SW). But let us just limit ourselves to SW for this argument, because it is the prevalent example. Clearly, if we are taking 2-3 years to come out with a system, then we are definitely going to be out-of-date by the time we roll things out. So, what is the alternative? How can we become smarter? Well, in my view, the Agile camp has taken this to the other extreme - they say, prepare a shippable product in 2-3 weeks. You didn't see, but my jaw dropped, and my mind went blank. But that is their message - once and for all. Do you agree? Isn't there something drastic about this? I think so.

Consider that you have to come up with a average sized system - consisting of various applications, systems, databases, web servers, application servers, languages, protocols, so on, and a bunch of NFRs(non-functional requirements). Let us say this is a airline reservation system. Now consider the business back-log - let us say that the top item (how it got there is a different story) goes something like this - 'the user must be able to make a reservation'. Now, the team picks this item, uses its understanding of that sentence to come up with tasks and - voila - they can indeed deliver it (in a 4 week sprint, let us say). No biggie here - one UI screen for selecting the flight, another for paying by credit card - and the system to do the actual reservation. After 4 weeks, the sytem is delivered - the product manager goes bonkers, he is pulling his hair - he says who told you to do it that way - and the team says - eh, what are you talking about - there is no such thing as you telling us 'how' to do it, we just do it, remember - there are no analysis docs or design docs - we just do it. Oh, BTW, you Mr. product owner - you should know Agile (or Scrum) better - the only artifact (contract) in these methodologies is the sticky - that small thing on which you wrote the 'user story' - and if you are looking for anything more you do not know 'Agile' - you are an ignorante (better yet, you are old-school)!

So, no documentation (my favorite) - do not 'waste' time by writing those tomes - BRDs, FRDs, TRDs, Analysis docs, Architecture docs, Design docs, anything - no docs, period. Start coding.

Where do these guys come from, seriously? BTW, you should read this  'Good Agile, Bad Agile' - dated, but still relevant. It is so eloquently written, it is a great read.

Frankly speaking, as I said earlier, I do not agree with the tomes concept, either. But 'nothing' is no answer either. A reasonable sized project will have at least 50 people - that is about 10 scrum teams. Imagine each one marching to their own beat (you can say, oh well, we have Scrum of Scrums - and my answer is 'without tools (read documentation), scrum of scrums is not viable - we cannot expect humans to be so smart that they can find discrepancies between teams just like that'). The problem is not just between cross teams, problems exist within a single team as well. First of all, if I am doing analysis, architecture and design for 'miniscule' components every sprint - that is one big inefficient process. I would say, take a sizeable chunk of deliverables (not just from one sprint), and do the analysis, architecture and (high-level) design in one shot.

What I am suggesting is that we should have mini-waterfall for some key aspects of a system - like the major use cases, high-level architecture, and may be high-level design. To be more clear - the idea is to start at the abstract for each of these, and then keep drilling down at appropriate points of time. For example, let us say that your system needs, ultimately, and taking a simple case, features for message queing, web services, and security. You do not have to architect all things in one shot - but, the key thing I would like to say is that - at the time you start working on the web services interface - take some time and architect for all your web services needs, not just for the first interface. Similarly, at the time you start working on the first security requirement, take your time to architect for all the security requirements. This, BTW, applies to all other aspects of SDLC - requirements gathering, analysis, and so on. Have requirements gathering - but just not like we used to do - for a year. Let us identify a part of the system (or whatever granularity), and work on that. The idea is to take maximum advantage of the type of resources required for each task - get together for 2 weeks (or 4 weeks), in stead of 6 months for requirements gathering or analysis. The end result is that you still produce guiding artifacts (which are very important for me), just not as bulky. That is a great advantage - you have the artifacts, but you are also delievering must quicker. Once we recognize that all this work is important and needs to get done, we can make it part of the cycle (rather than just discounting it and 'assuming' that they will 'somehow' get done, as Scrum does). Heck, I feel like I should start promoting these ideas - may be I will write them up (oh wait, do I have to find a catchy name first? 'mini waterfall' may not cut it).

There are many other problems with Scrum, and I can keep going on. For example, Scrum is totally vague on when they can get things done (precisely because they do not do upfront analysis or architecture or design). If I were a product owner, I will scoff at it. I do not want such a team - see, at some point, I want to draw a line. Enough - I want some predictability - I want to be able to demand certain professionalism. I hope all product owners will stand up and say 'enough'! Heck, I hope everyone will stand up and say 'enough'!

Secret questions

In a way, this is my pet topic. If I find nothing else, I resort to cribbing about security questions.

The problem is that these security questions have tripped me so many times - they are kind of harassing to your mind. One may say that they may be challenging, not harassing, to put in an intellectual way - challenge you to think of the same answer everytime. But, see, I have other challenges in life - I do not need this additional one - something that is thrown at me rather than me choosing it. I hate these questions.

There are two types of questions - ones for which anyone can find out the answer by doing some background search, and others for which no one, not even I, can remember the answer for. Are there any others? I do not think so. 'What was the favorite place to visit as a child?' - secure, but answers could be really random, I wanted to visit so many places when I was a kid - but, heck, I do not even remember them now! 'Who is your favorite actor?' - either I blurted that answer in a public forum some way, or I do not have just one actor (also depends on genre). Name a question, and I will tell you at least one reason why it does not work for me.

Some have really researched this stuff and have come up with 'good' examples, and 'bad' examples. They prescribe a process by which you can come up with good questions and detect if a question is bad one. See goodsecurityquestions.com, for example. But in my view, this is a waste of time - just plain get rid of them. The only reasonable approach I have seen is at the OWASP site (see Parola Secreta?). They they do recommend policies to adopt for security questions and their implementation, they upfront tell you why security questions are weak. That list of weaknesses itself should close the case here. Another great advice from OWASP - "Providing the answer to a secret question should never be enough to validate a user, but combined with other factors, such as having access to the user's e-mail account, secret questions can be effective in helping to identify a user."

Another problem I have with security questions is that I do not want to share my 'secrets' with all these web sites. I have different passwords for my bank, mail, blog, so on. But guess what, my mother's maiden name is only one! Do I want to share that with buycheapink.com? I guess not. I do not mind creating an account with buycheapink.com, but I do mind sharing my mother's maiden name with them.

More frustrating than these questions themselves is the way people latched on, and refuse to leave, this technology. People, listen to me, it is just plain frustrating to users! Get it? Just do not make us go through them. And the real frustration comes from the fact that there are other, simpler alternatives. Send an email - simple, isn't it? Bank of America has instituted a password reset process that relies on your card # and other data on the card (alongwith last 4 of SSN, of course). That works for me. See, if you apply your mind, alternatives come easily. The thing is that the right solution is dependent on your business - not on a pattern from the industry. You need to have security expertise working on it, not just about anyone, but remember that the right solution for your business comes from your business.

I hate security questions.

OAuth and Twitter

Recently, I came across this article - Compromising Twitter's OAuth Security System.

At first blush, it looked to me like a frank (objective) look at a technology and issues with its implementation – way different from the flattering, fanning the hype kind of articles we typically come across.

However, it serves to decompose, or strip down the article to its main points (its quite verbose), and see what the conclusions are. The first point (written in couple of pages) is that Twitter's OAuth implementation is bad because it requires client credentials even for desktop/mobile applications (such applications will have to embed the secrets in their binaries). And that since such binaries can be easily reverse-engineered, hackers can get to such secrets easily. Fair enough. The article does note that Twitter did offer some alternatives - like per instance registration, or having a user specific component for the key. However, such alternatives are shot down in the article as either inconveniencing the user, or not actually implemented by Twitter. FOSS has been made a focal point of the argument as the source code is open, thus the keys are going to be necessarily open.

OK...fair points all. But what are the alternatives? One suggested one is 'remove any client authentication for such applications'. Wow! This is where I so much differ. (Kind of like - what did you just say?) To quote from the article - "If Twitter does the right thing and eliminates the requirement for desktop applications to use secret keys, it would effectively resolve the problem for FOSS clients." Apparently, Google and Facebook, according to the article, have come up with “reasonable solutions” - to quote from the article "... that do not require a secret key or require the end user to go through a complicated copy/paste process". So, is absence of security is what we are after? (Actually, FB comparison is not apples to apples, as FB implementation is based on the draft 2.0 spec.)

However, I do agree with couple of points raised in the first section of the 3rd page - one is to do with the user NOT being logged out of Twitter after the flow completes, and another to do with the misleading interpretation of the 'Deny' action. To me these are important considerations and ones that can be easily fixed.

On the 2nd section of the 3rd page (about phishing risks), though, not sure what others are doing here, but there is an important detail that has been left out. The key here is that the user is on the client app's page before the flow starts. This means that user is aware of the authenticity of the client web site - and even if they are not aware, it is their responsibility to know to whom they are giving authorization. I do not expect (nor does the standard anticipate) Twitter (or any others in that role) to properly vet the client web sites. The protocol allows only that who made the original request is the one that actually gets the authorization. It is up to the end user to verify which client web site they are dealing with. A related technology is EV SSL certificates (which, BTW, have been brought about after decades of public PKI). But EV certs are offered by a much controlled process, and costs money. I do not expect such a process to be put in place for a photo sharing web app.

The article concludes that 1.0a version is "...a horrible solution to a very difficult problem.". I would not use such sharp words. We have to recognize that for any technology to mature, it takes time, and more importantly, no single technology can address all the scenarios. Heck, physicists have been trying to come up with a unifying theory that explains everything in the universe, but so far they could not - meanwhile, we have relativity theory, quantum theory, Newton's theory and so on! I can live with that.