OAuth - Part 3: Third-Party Applications
What are we talking about?
Historically if a customer wanted to build a software application that interacted with Anaplan, a service account would need to have been used to authenticate into Anaplan. I will be incorporating an OAuth flow into my application that lets users sync multiple production models from a single dev in one click.
It would be helpful to review that app in this article as I won’t go over the functionality again here. You will notice in the application there is a “login to Anaplan button” which is really just using a service account’s credentials to authenticate into Anaplan.
Why does this matter?
The difference may be subtle but is very important.
Using OAuth, the end-user can now grant access to the application to act on their behalf in Anaplan without having to turn over their username/password combo. This is important because it allows the app to perform actions as if it was a particular user, rather than using a service account to authenticate into Anaplan. This allows the app to respect any and all user management configurations set up in Anaplan (model access, roles selective and dynamic cell access, etc.).
For example, the service account could have access to models the user should not, and a potentially illicit action could be triggered by someone with inappropriate access. Using OAuth, any actions the application performs are done as if the user themselves was doing it in Anaplan.
This demo video shows how simple the end-user experience is for a user to open the app, let the app act on their behalf, and then go about their business with no further thought.
I’ve chosen not to provide a detailed technical spec for this app in this article, but if there is an appetite for it I am happy to provide it in subsequent articles.
Got feedback on this content? Let us know in the comments below.