Why you shouldn’t use cookies for Native Mobile Authentication

Can I Take a Cookie?

So, I finally decided to put up this post because internet search results seem to be limited on this topic. This is about using cookies as a form of authentication in native Mobile. I scoured the internet and came away with the impression that the answer to this question was either hush hush or everyone seemed to have just followed the bandwagon or de facto approach of using basic authentication (over https) and now OAuth 1 or 2.

Don’t get me wrong I’m a big proponent of using OAuth 2.0, but it happened to be the up and coming standard when I really got into Mobile dev and Architecture. And every so often, I get the question from old school service developers, “So, why exactly can’t you use cookies with Mobile?” and I respond “Huh… well it just doesn’t work well with it . OAuth, Yes OAuth! We should be using token based authentication and basic auth over https only as the alternate option”. I immediately walk away as fast as I can before more questions pop up.

Is it Just Me or What?

I got by with this answer for quite a while, but recently I could not take it anymore so I jumped on the ‘interwebs’, busted out google and … crickets. Here and there you see some info, but the feeling you get is that person writing kind of knew, someone who knew someone, who knew the guy who really knew the answer. So I felt a little better that maybe I’m not alone after all. Basically, sparse indirect answers.

A Bit of History

It’s probably safe to assume that if you are reading this blog you likely know how cookies work, but just in case check here for a quick run down. Basically, cookies started with Netscape’s (remember them) desire to maintain the contents of a users online cart and the rest is history. Today cookies provide a great way for storing an encrypted version of a user’s identity, so you can be remembered in subsequent requests on a web browser. So technically, this should be feasible on mobile, right?

Any Beef with the REST Based Standard?

No! Like I said before I will recommend OAuth 2.0 to anyone who has an ear to listen to me. It may not be perfect, but I certainly think it’s the best solution out there. A token based solution that never has to preserve a user’s credential on the device. How sweet. Basic Auth typically requires you send up the credential with every API request and you better do that over https. But, more than likely you have to preserve the user’s credential even if it’s just in memory. So why not cookies?

The Why Not

After much frustration and poking around, a buddy of mine found some answers at the very place I should have looked first (thanks Michael Clark and Wikipedia). The HTTP cookie page discusses drawbacks to using cookies especially on native mobile. I have to say I have not validated some of the reasons through development and extensive testing, but the reasons make complete sense. To summarize

  • Most devices do not implement cookies natively
  • Some gateways and networks strip cookies
  • Some networks simulate cookies on behalf of their mobile devices

These are reasons in addition to typical cookie issues, like expiry, theft etc. Basically, using http cookies on Mobile Native is unreliable. That is enough of a reason to avoid it like a plague. At least now you no longer have to play Houdini when asked that question. It won’t surprise me if you have found other better reasons in some remote corner of the internet as of writing this. But, I would sure like to hear what those reasons are. So, do share. I hope this has served you a real good reason for not using  cookies for native mobile authentication.

0

Autonomy, Mastery & Purpose (AMP): Keys to getting the most of out your team

nightliteWhen people are inspired, things get done and done well. Consciously or not, a work environment impacts performance and satisfaction level of a team. Managers find themselves either using a carrot or stick to get the most out of their team. But, this has its limits for driving performance. How do you inspire?

Enter AMP: Autonomy, Mastery & Purpose. These 3 elements can take a team a long way.

Autonomy:

Giving individuals and teams a level of autonomy not only encourages innovation it actually increases satisfaction. If you think about activities you participate in, you are likely to be more satisfied and perform better in the ones where you have a say and some level of control.  A simple example of this is an organization that gives its employees the choice of what dev tools they want to use (Mac vs Wins vs Linux) as long as they generate code that is reusable across teams.

Mastery:

A role that provides a sense of mastery is simply unbeatable. Numerous researches have shown that one of the reasons top performers change jobs is a lack of challenge and complexity at their current role. Think Maslow’s hierarchy of needs for self-actualization. We all are driven by a sense of mastery. Why do you think people get hooked on games like candy crush and angry birds? Ideally, it would be great if the actual day-to-day responsibility provides an avenue for learning and mastery. An alternate real world application of this is to find out what certifications or technologies people are interested in (which also add value to your business) and look to support them in that pursuit; if not financially, then through rewards and recognition.

Purpose:

A sense of meaning can never be understated. Why are we doing what we are doing? It’s so easy to get focused on the ‘What’ and lose a sense of the ‘Why’. Understanding the why is what inspires. An organization struggling with understanding or communicating their ‘why’ cannot be a top performer in their industry. Also, loosely tied to this is the ability of an individual to clearly see the connection between effort and reward.

What could these 3 elements look like in your organization? It’s worth giving some thought to. I believe this lesson is also valuable for individuals as well who are evaluating potential companies to work for. It also makes for good talking points during yearly performance review in a company you feel valued at, but they can’t quite figure out how to help you perform better or make your job more satisfactory.

0

Did someone lose Architecture’s invite to the Agile party?

Image

It sure is awkward showing up to party and realizing it was invite only and you are not sure you ever got one. Similarly, there’s a weird tension that exists for any Architect that gets injected into a true Agile development environment for the first time. No longer are there extensive drawn out sessions and phases to layout a long term plan and design to build something to last ‘forever’. Scrum Teams are self organizing and everything is evolving so rapidly.

It’s likely less dramatic, but the tension is real. The open question exists : “How much architecture needs to be done upfront vs how much should be deferred until the requirements are nailed down?” In reality a rapid development environment, like Agile leaves little time to address cross cutting concerns and setting up all the infrastructure needed for a large scale system. Such an activity also requires a broad view across multiple features and teams.

There’s sort of a trade-off; You spend too much time up front planning and you lose your ability to adapt to changing requirements. You move too fast and it could be chaos. One recommendation is to go with what George Fairbanks terms “Just enough architecture.” But, what does that really mean and how does it apply to different complexity of projects? Like Rick Kazman once illustrated, building a shed is so much different to building a skyscraper. While it’s easier to operate within a self-organizing team when building the former, the latter requires more attention to detail. On the flip side, it’s simply a waste of time to devote the same amount of time upfront building a shed as you would a skyscraper.

George Fairbank’s comment is really hinting on having the right amount of architecture at the right time. Overall, I believe risk reduction should be the chief motivation in how we approach architecture in Agile. It should influence how an Architect approaches documentation and evaluation as well (twin tension points for Architects in an Agile environment).

So how do we hit the ‘Sweet spot’ between upfront planning and agility? Here are 5 things I have learned

·  Focus on what poses the greatest risk to the system’s main function and qualities. Then channel your energy to mitigate that risk.

·  Seek to architect around separation of concerns, loose coupling and decomposability.

·  Document only what is needed. If there’s no audience for your documentation you probably don’t need it. If there’s a part of the architecture that a lack of clarity for a newcomer might become a RISK for the project/system, document it. Also, starting with a design that captures simple end to end functionality upfront is a reasonable goal.

·  Lean on good code and test suites to reflect architectural patterns and decisions.

·  Emphasize experimentation (Spikes). And take advantage of such agile principles as an Architecture Runway and Technical debt. Discipline and rigor around them allow for resolving trade offs.

In conclusion, Architecture might no longer get a red carpet like it used to in dev gigs, but there’s no doubt that it definitely does have an invite to the Agile party.

3

Blog at WordPress.com.

Up ↑