Goldcrests Commando Project Post-mortem
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:
Create a Web Service that increases followers for a registered user based on a user-defined keyword. This would be achieved through retrieving statuses with that keyword and liking those statuses.
Project Tasks Completed by the Team:
- Front-end design
- 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:
- Routes for storing and retrieving data from the database
- Twitter access token and access token secret for the logged in user
Auth0 Service Investigation:
Auth0 is a third-party identity management provider that developed a ‘zero-friction’ solution for developers. The majority of the team was unfamiliar with OAuth and the Auth0. As a result, the project ended with a level of uncertainty as to whether the Auth0 service would have actually met the requirements of the task. For personal discovery and knowledge, I spent some time after the commando project determining if the solution was viable.
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.
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: https://auth0.com/docs/migrations#identity-provider-access-tokens-removed-from-user-profile-and-id_token
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: https://auth0.com/docs/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api
Please let me know if this answers your question.
Thanks,
Thameera
Developer Success Engineer — https://auth0.com
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:
During the project, Chandler Mayo, our team member leading the configuration of the Auth0 service, mentioned integrating the MySQL database with Auth0 directly. We opted against so that all data incoming and outgoing pass through our web service’s API. After reviewing the Auth0 interface, I would probably reconsider that decision if we were doing the project again. The reason is that their service is already handling our identity management and half of our database was the data retrieved through their service. Connecting our database to their would have reduced our workload on a short timeframe.
Security Concerns:
During our closing presentation, Omar Alaouf, a mentor at Holberton School, brought up the concern of security and the need to setup SSL. Given that we would have a token and token secret that can be used to control a user’s account through the API, I would reaffirm that SSL should be in place if we were to redo the project.
Lessons Learned:
Holberton School’s focus is project-based, peer-learning. These commando projects provide us the opportunity to think through building services under pressure, but in evaluating our work we can learn even more on how to improve our process in the future. Some things we could do differently based on this experience include:
- 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.
