Blog da AdviseU - OAuth0: Erros para Amar

Auth0: Mistakes to Love

4 Sep 2020 | OAuth, OAuth0, Optimization

Peer feedback is essential in deciding on vendors and seeking advice on technology problems. Decision-makers responsible for an identity implementation across an app development team can use peer feedback to learn about – and avoid – others’ mistakes.

Expert advice is great, but sometimes the most practical advice comes from those who are trying to accomplish the same goals as you are, and who may have learned from mistakes the experts hadn’t even thought about.

A survey asked your peers about the mistakes they made and how they worked with other teams on previous identity projects, both when they bought and when they built. A successful identity project is never achieved in a vacuum, so we also asked about the mistakes they made in the architecture surrounding their identity implementations.

Getting it right: The mistakes

Identity decision-makers, as self-identified technical decision-makers who remove barriers, define architectural workarounds, and understand the associated product implications, can speed up their own learning by seeing the mistakes others have made in their own projects

So the respondents in this survey generally prioritized security, integrations and compliance, in that order, across all the identity projects.

The most commonly cited mistakes in build scenarios had to do with underestimating scope, timing, resources required, and complexity:

“The biggest technical mistake was underestimating how much time and effort it would take to develop a secure and robust [identity and access management] solution. It simply took up way too much time to ensure we were secure enough and could integrate with other identity providers”.

The second most commonly cited mistakes in build scenarios involved designing, planning, and testing:

“Not making a 100% complete list of regulatory and industry (healthcare) constraints applicable”.
“Ignoring legacy systems that would be part of a larger implementation plan”.
Not having a “clear map of internal services/ applications and dependencies”.
“Incomplete assessment of infrastructure components”.

Interestingly, user experience was not mentioned at all as a challenge in build scenarios.

Mistakes in build scenarios

The most commonly cited mistakes in buy scenarios had to do with integration of the identity solution to apps as well as to other parts of the architecture surrounding the solution.

“Integration to custom-built solutions has been challenging”.
Interfaces with other systems, such as customer service solutions.
Integration with cloud and on-premises platforms.

The second most commonly cited mistakes in buy scenarios involved vendor business issues:

Licensing.
Problems with the vendor’s roadmap direction.
Tech support.
Feature options.
Not based on standards.

Mistakes in buy scenarios

Other elements you are deciding on with buy versus build:

Skill, roles, and resources were much less of a problem in buy scenarios versus build, and the problems were of a different nature. In build scenarios, the primary issue was internal skills. In buy scenarios, this still mattered, but there was also an issue of external consulting resources. For example, having to rely too strongly on external expertise to get the solution running.
Poor execution and implementation mistakes that were present in the build scenarios virtually disappeared in the buy scenarios.
Scope estimation was less of a problem in buy scenarios, representing only 7% of mistake mentions compared with 20% in build scenarios.

Not surprisingly, failing to select “a vendor that can adjust to future needs” was a mistake mentioned in the buy mistakes section only.

Mistakes in the architecture surrounding identity

Firstly, the most commonly cited mistakes in terms of the architecture surrounding the identity solutions had to do with designing, planning and testing:

Not properly assessing the current (and sometimes inherited) environment.
Considering identity factors like SSO, multi-factor authentication and social logins too late versus earlier on in development.
Not taking the time to fully understand the identity solution and map out objectives.
Starting too big versus too small and then scaling. Also not testing small bits and then scaling after successful tests.

Moreover, mistakes mentioned in the architecture section exclusively:

Resiliency, delivery model, microservices, and continuous delivery models.
Overall platform standardization.
Storage of user names and passwords, other data issues.
Cloud versus on-premises considerations.

Conclusion

Any technical decision comes with good and bad experiences. Understanding others’ experiences is the quickest way to shorten the learning process and come to your own conclusions.

Regardless of whether the decision is buy or build, given the weight of responsibility on the shoulders of identity decision-makers, talking to a vendor like Auth0 can provide a realistic view of a buy scenario with options for customization.

Finally, there’s much more in the complete and free ebook “Mistakes To Love: A Survey of Identity Mistakes”. Take the opportunity to download and read whenever you want or consult whenever you need.

0 Comments

Submit a Comment Cancel reply

Follow us!

Privacy Policy Terms of Service AdviseU Web Portal