I am working on a plugin that I would like to add Google and Okta single sign-on (SSO) to. Has anyone worked on something like this before? To clarify, it is not that I want to add SSO that would let a user log into an Adobe service - rather, what I am trying to do is to add SSO that would let a user go sign in to one of my company’s services by accessing SSO through the plugin that we have built. The idea is that there would be Google and Okta SSO buttons right in the plugin UI and then when the user clicks one of those, the click would initiate the appropriate SSO flow that would then end up with the user authenticated as far as our back end is concerned. The point of the user getting authenticated is so that the plugin could then fetch various kinds of information from our back end for that specific user.
I think that this is possible in Sketch because you can get a Sketch plugin to go to an arbitrary webpage and it will even run client-side code on that webpage if necessary, it will follow redirects, etc. - just like a web browser. But XD does not expose full browser-like functionality, so it seems like in an XD plugin it would not be possible to just use the same kind of redirects-based SSO flow that the user would follow to sign into my company’s service through SSO in a web browser. But maybe there is some other approach that I could take. I guess that in a more general sense, since XD does not have a webview, I am also asking “how can you implement Google / Okta SSO outside of the context a web browser or webview?”.
Yes, although it’s not the easiest thing in the world for now. (Hoping to improve this in 2022.)
For now you have two options (both have their issues):
Launch the user’s browser and also start an auth service on your backend. Upon authentication, the backend updates with the user’s information, and your plugin will have been polling to get access. (There are some risks here – talk to your security folk before going this path.)
Follow the device grant flow that you see on TVs and the like – the user is directed to a website, they login, and then given a code to enter back into the plugin. (UX concerns here, and double check w/ your security folk!)
Note that even when Webviews in Modal Dialogs are supported, you should not use them for Oauth – Google services especially are becoming more restrictive here because there’s an entirely different class of security concerns that can arise from this.
If everything goes to plan, in 2022, you’ll have an API that’s dedicated to Oauth and making it easy to essentially deep-link to your plugin so that it can be the last step in the auth process.
Thanks @kerrishotts! That is very helpful. We would like to find out as much as possible about the security concerns for both options before we start trying to implement this feature in our plugin. Any details that you could provide about those security concerns would be great for us to know about.
Hope I’m not too late to jump in here - I am trying to implement SSO in my panel - I am able to route to the signin app, how do I route back to the panel with my token?
