0

Just for some context, I am a CS student in my second-year who is working on a C++ desktop application (using the Qt framework) made by an engineering professor.

The application is an educational tool for instructors, but also involves student input. In essence, the desktop application can interact with multiple different learning management systems (LMS--think canvas, blackboard, google forms... etc.) to create surveys that the students can complete. So, for example, teacher creates a survey, and wants to gather input from a google forms; the application has to then communicate with the Google Forms API and create a survey in Google Forms. Then the instructor can share that survey with the students so that they can complete it. The idea is that the application can also do this with canvas quizzes, etc.

I have been tasked with exporting the API communication to a separate server, kind of like a restful API (I apologize if I am using that terminology incorrectly). So, the desktop client should talk to the "restful API", and the "restful API" should talk with the necessary API based on the client's request (Google Forms API or canvas API or Blackboard Api...) and then the "restful API" sends a response back to the desktop client on behalf of whichever API was originally requested. This is how I imagine it should work anyways. I am using Flask and Python. In other words, the API I create should be responsible for managing the communications between any desktop client and an LMS API such as Google Forms, Canvas etc.

One big issue I've encountered is as follows: how can I deal with OAuth2.0 from APIs like Google for talking with the Google Forms API? If, for example, a desktop client sends a JSON message to this "middleware" API I've created, asking to talk to the Google Forms API and create a Google Form, how can I have the API talk to the Google Forms API, and then redirect the authentication link back to the client (because the client has to provide their login details)?.

In other words, how can I deal with authentication from the user when using this kind of setup ( (desktop client) -----> (My API) -----> (Some requested LMS API) -----> My Api -----> (desktop client) )? I want the RESTful API I create to deal with the "LMS stuff", but I need authentication from the desktop client.

Feel free to criticize anything about my task for the project. That includes an approach that you think would be easier/cleaner to implement to accomplish this goal of simplifying the communication of the desktop application with other APIs. If I had the time (I'm working on this part-time during the school semester) I would personally redo the whole thing and implement the software into a web app, but that would require a ton more time and grant money (there is a finite amount).

Improve this question
5
  • 3
    Authentication is a very broad topic with many answers based on your requirements. There are many equally valid answers to this question, which doesn't fit the Q&A style of this community.
    – Greg Burghardt
    Commented Apr 17 at 19:12
  • 1
    Many OAuth providers use JSON Web Tokens. Basically, your desktop user needs to authenticate with Google, your desktop application gets a JSON Web Token (JWT) and passes that to the backend which calls the Google web APIs, likely passing the JWT back to Google. This is one of many ways to do this sort of thing, though.
    – Greg Burghardt
    Commented Apr 17 at 19:15
  • @GregBurghardt Ok, thank you for the feedback. I'll keep that in mind for future posts. I was under the impression that I could ask more architecture-based questions on this forum. I will look into and learn more about JSON Web Tokens
    – Johnny
    Commented Apr 17 at 20:48
  • Architecture questions are on topic, however general questions are difficult to identify a single comprehensive answer. It's the broad nature of this question that is challenging.
    – Greg Burghardt
    Commented Apr 18 at 0:28
  • If you don't mind me asking. What advantage does this server provide? It seem to add a fair bit of complexity, so the advantages need to be proportionally large. To me this seem like a fairly risky project, so you might want to plan accordingly.
    – JonasH
    Commented Apr 19 at 15:13

1 Answer 1

Reset to default
2

As Greg Burghardt's comment points out, this authentication problem is handled by having your clients produce tokens for the ultimate API they're interested in, and then your server will simply forward those tokens.

Taking a step back, I think it might be worthwhile exploring the option of not having that intermediate server at all, and handling all of the provider APIs from your desktop application directly. What's the added value of this additional server? If this was a real life application, this would be a key question. Making the server sounds like it's the point of the exercise though, so it's just an interesting thing to think about.

Another thing that comes to mind is how your server should deal with multiple clients using it at the same time, each with its own authentication token(s), and maybe even targeting a different provider API. Does the business logic require your server to have a stateful representation of each client and some piece of session information (authentication data, survey...)? If not, this makes things much simpler to think about.

Improve this answer
1
  • Since the OP mentions part time work, I would assume this is payed work and not a learning exercise. So questioning the purpose and architecture seem perfectly appropriate to me.
    – JonasH
    Commented Apr 19 at 15:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.