OK, so Adobe recommends using an external server for OAuth workflows –
https://adobexdplatform.com/plugin-docs/tutorials/how-to-integrate-with-OAuth/
– but since the final OAuth redirection can occur to a localhost URL (that’s what we do in our InDesign DocsFlow plugin that interops with Google Docs), is there any way for an XD plugin to establish an HTTP listener on a non-privileged port?
That would solve the problem of needing an external server that you poll to get the session ID, etc.
Pretty please, @kerrishotts? 
2 Likes
OAuth workflows are always on our list, and we’re looking at ways to improve the developer experience there. I don’t have any firm details at this point though (we’re considering several options, but need to be able to ensure the security of the session. So to start we’re working on secure local storage, and things will build from there.)
3 Likes
Oh, secure local storage to store thinks like JWTs?
Hey Chris,
maybe you want to have a look at the OAuth 2 Device Flow: https://oauth.net/2/device-flow/
If you think of the YouTube app on TVs for example - they are using it and it feels very convenient.
I am not sure if it is the same experience when sitting in front of a desktop computer where you have a full keyboard in front of you.
It is not a standard yet, but I have implemented it in some apps (not XD currently). This would require the user to open a browser window, sign in and register the XD instance with the code shown in the panel or dialog.
However, this way you would prevent entering credentials into the XD extension and get an access token.
Interesting! That’s a creative approach–let Google (or whatever OAuth server supporting this flow) do all the work.
Don’t know if it’s as “satisfying”/smooth in that you have to manually enter a code instead of just being taken to a normal Google (in my case) login screen in the browser.
Though I guess the plugin could launch a browser window after copying the device code to the clipboard, asking the user to paste the code.