Authentication, Authorization, and Access
This post is part of a series of posts I’m writing as part of my“build in public” project.
Context
I decided to create a small social media post scheduler a few weeks ago. My plan was to use it as an excuse to experiment with some AWS services and it’s working so far. I am also using this opportunity to join the build in public initiative. It involves tweeting (or posting in my case) the progress of your project from time to time. However, I might be too late for the party as the website seems to be inactive. Nonetheless, the philosophy is still interesting and valid. I plan on updating my progress from start to finish as I go, without leaving out any gory details and frustrations.
Authentication and access to AWS resources
I started with putting together the pieces for authentication and authorization and decided to use AWS Cognito. I also put a constraint on myself to enforce good tenant isolation even if I don’t really need it for an MVP. You can see a detailed article on using Cognito and tagged user sessions for tenant isolation that came out of this work.
For the MVP I’m focusing on Linkedin integration. A user can log in to my application via LinkedIn and provide permission to post on their behalf. Once the permission is provided, they can download a text file (post pool), write their posts in it, and upload it back. The application will publish (push) one post from this file (pool) to Linkedin every day.
For login, I configured a Cognito User pool with a LinkedIn Identity Provider and implemented the authorization code flow. Next, I set up an Identity pool for the User pool and created an authorized IAM role that I can assume on behalf of the authenticated user. (see details here)
LinkedIn Authorization
Once I had the intricacies of Cognito Userpool and Identitypool worked out and had a good enough mechanism in place to allow users to get authorized access to my core APIs, I realized that I was now dealing with 2 sets of Identity tokens, access tokens, and refresh tokens. The access token I received from Cognito was to grant access to the internal AWS resources. I needed another access token from LinkedIn to be able to push posts on a user's behalf. Since the grant flow and terminologies are almost identical it was a bit difficult to account for all the possible states and flows in my head. So I went to the drawing board to get it out of my head. The diagrams you’ll see below are a mix of state and sequence diagrams. They can be much more refined but the goal is not to create lasting documentation right now. I’m using it to aid my mental model without investing too much time.
The diagram above accounts for all possible states of a Cognito Access Token stored as a cookie in the client web browser and included as an authorization header for every API call.
The diagram above covers the request that will allow a user to grant permission to push posts to LinkedIn. As I was drawing this, I realized that I wasn’t sure exactly how the redirects would work and this will require a quick PoC to confirm.
The diagram above covers all possible states of the LinkedIn tokens that the post scheduler (scheduled job) will have to deal with.
Conclusion
Using the whiteboard to jot down all the possible states and think about the actions they can lead to, helped me expand my mental model, optimize certain flows, and reduce the cognitive load of dealing with two sets of tokens and two very similar auth flows.
Have a look at the flowchart of both login and authorize flows and you’ll see just how similar (and hence confusing) they can be
Now with these diagrams, I’ve more clarity about what I need to implement and my next post will be an update on LinkedIn authorization and maybe even the scheduler. Currently, I’m only able to invest a couple of hours per week in this project so the progress is slow but so far it has been fun.
