Goldcrests Commando Project Post-mortem

Rick Harris
Jul 22, 2016 · 5 min read

On Tuesday, July 19th Holberton School students participated in a commando project, similar to a hackathon. We were split into two teams and given a task to complete. This task was for educational purposes only. In other words, “Don’t be mad Twitter.”

Project Goal:

Project Tasks Completed by the Team:

  • Twitter Login on our site using Auth0
  • Connection From Auth0 to our web service’s API
  • MySQL Database Setup with Required Tables
  • Bot to Like Statuses Based on Keyword

Incomplete Project Tasks that would have been Essential to a Functional Product:

  • Twitter access token and access token secret for the logged in user

Auth0 Service Investigation:

Permissions displayed on Twitter under Settings > Apps after a user logged in on our service

There were two separate issues that we were facing. The first issue dealt with the permission level of the consumer keys our app was using. The consumer keys authorize our app to connect to Twitter user accounts at the requested permission level. Each user is prompted to accept or decline the level of access an app requests. Our configuration used development Twitter keys provided by Auth0. These keys only gave read access. This is perfect for using the service for login only, but would have prevented us from actually liking statuses on behalf of the user. This is a fairly easy fix that would require registering the app with Twitter, getting consumer keys with read and write privileges, and configuring them within Auth0’s service interface.

Example image in documentation from Auth0 displaying the access token and token secret which should appear in the response. The actual values were removed from the image.

The second issue is that we were not receiving the Twitter access token and access token secret after a user logged in. The documentation indicated through a screenshot that it would return that information. However, all tests on our part indicated otherwise. As a result, I logged a support ticket with Auth0 given the contradicting information. The case was escalated to the Developer Success Engineering Team. I received the following response last night.

Hi Rick,

You are correct; the Identity Provider’s access token is not sent along with the user profile anymore due to security concerns. The documentation is currently being updated and I’ve escalated this to the documentation team to update the screenshots as soon as possible. Really sorry about the confusion.

You can read more about this change here:

After the user logs in, you need to call the Auth0 Management API from your backend to obtain the access token. There is a step-by-step guide here:

Please let me know if this answers your question.


Developer Success Engineer —

Conclusively, it is possible to obtain the token and secret through the Auth0 service. Therefore, it is a viable solution for this task.

Auth0 Database Integration:

Security Concerns:

Team planning session at the start of the commando project.

Lessons Learned:

  • Evaluate the unknown — Our biggest knowledge gap on the team was working with API services that require OAuth. This also happened to be the most critical item to our success. Given the priority and importance of this requirement, we should allocate more resources to evaluate several options. Evaluating options provides a backup plan in case the primary solution falls through.
  • Simplify with integrations — We passed on integrating Auth0 with our database to funnel input and output through an API. If secure integrations already exist which can also reduce workload, we should use those integrations.
  • Always consider security — When dealing with data, security of the information is critical. The team should be working to secure our services whether setting up SSL or configuring a deployment process to keep developers from destroying the server configuration.

Rick Harris

Written by

Full-stack Software Engineer | @holbertonschool Student | Fan of the @FightingIrish | Opinions represented are my own.