how to keep Google/Facebook logins from conflicting

131 views
Skip to first unread message

Cyrus Adkisson

unread,
May 27, 2014, 2:21:12 PM5/27/14
to chromium-...@chromium.org
It dawned on me today that my extension, which uses Google and FB for third party login, might conflict with other extensions doing the same thing.

For detailed information about how the login works, see http://blog.words4chrome.com/?p=54

The short version is that when the user authorizes my app via Google or FB, there is a redirection to a google or FB url where a "code" appears:


Via a content script, my extension grabs the "code" and completes the login. 

My question is, what would prevent other extensions from interfering? I'm not so concerned about possible malicious use of the code since it's worthless without my G/FB apps' secret keys... I'm more worried about other extensions listening on those URLs and executing scripts to read the code at the same time my extension does. Heck, my extension could potentially do that to THEIR login processes. 

How would one go about preventing these conflicts?


Jamie Walch

unread,
May 27, 2014, 2:26:31 PM5/27/14
to Cyrus Adkisson, Chromium-extensions
For the Google login case, have you looked into the identity API (https://developer.chrome.com/apps/identity)? It has a launchWebAuthFlow method which largely replaces the use of content scripts to do what you're trying to do. If you can't use that, consider including your extension id in the OAuth2 redirect URL and matching on it in your content script.


--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/b181feb7-71fb-406f-9646-e1e9e4d36e99%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

Cyrus Adkisson

unread,
May 27, 2014, 2:52:43 PM5/27/14
to chromium-...@chromium.org, Cyrus Adkisson
I implemented getAuthToken and launchWebAuthFlow (I'm 90% sure) a while back and eventually reverted. I posted about the experience here:


Also, for a chrome extension, there is no redirect URL. The redirect goes to a default google/facebook page. Are you saying that launchWebAuthFlow will let me use a chrome-extension:// url?

On Tuesday, May 27, 2014 2:26:31 PM UTC-4, Jamie Walch wrote:
For the Google login case, have you looked into the identity API (https://developer.chrome.com/apps/identity)? It has a launchWebAuthFlow method which largely replaces the use of content scripts to do what you're trying to do. If you can't use that, consider including your extension id in the OAuth2 redirect URL and matching on it in your content script.
On Tue, May 27, 2014 at 11:21 AM, Cyrus Adkisson <cyru...@gmail.com> wrote:
It dawned on me today that my extension, which uses Google and FB for third party login, might conflict with other extensions doing the same thing.

For detailed information about how the login works, see http://blog.words4chrome.com/?p=54

The short version is that when the user authorizes my app via Google or FB, there is a redirection to a google or FB url where a "code" appears:


Via a content script, my extension grabs the "code" and completes the login. 

My question is, what would prevent other extensions from interfering? I'm not so concerned about possible malicious use of the code since it's worthless without my G/FB apps' secret keys... I'm more worried about other extensions listening on those URLs and executing scripts to read the code at the same time my extension does. Heck, my extension could potentially do that to THEIR login processes. 

How would one go about preventing these conflicts?


--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

Jamie Walch

unread,
May 27, 2014, 3:06:47 PM5/27/14
to Cyrus Adkisson, Chromium-extensions
According to the docs, it actually redirects to https://<app-id>.chromiumapp.org/*.

Chrome Remote Desktop uses a flow similar to the one I suggested, and we're in the process of migrating to the identity API. You can see how it works here. Specifically, identity.js is a wrapper for the identity API, and oauth.js does the app-id-dependent trampoline for the non-identity flow, and third_party_token_fetcher.js uses the launchWebAuthFlow API.


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

Cyrus Adkisson

unread,
May 28, 2014, 9:41:26 PM5/28/14
to chromium-...@chromium.org, Cyrus Adkisson
Jamie, 

Thanks for your responses. I've got the launchWebAuthFlow() stuff working now and have nixed cookie storage of google and fb access tokens altogether.

The problem now is that if the user wants to log in under a different google account, the previously stored access token keeps getting used.

In other words, how do I purge the authorized token from the special cache?

p.s. removeCachedAuthToken() doesn't seem to work and chrome://identity-internals/ shows nothing to begin with. Completely blank. Me = confused. Is removeCachedAuthToken() only for getAuthToken() and not launchWebAuthFlow()?

On Tuesday, May 27, 2014 3:06:47 PM UTC-4, Jamie Walch wrote:
According to the docs, it actually redirects to https://<app-id>.chromiumapp.org/*.

Chrome Remote Desktop uses a flow similar to the one I suggested, and we're in the process of migrating to the identity API. You can see how it works here. Specifically, identity.js is a wrapper for the identity API, and oauth.js does the app-id-dependent trampoline for the non-identity flow, and third_party_token_fetcher.js uses the launchWebAuthFlow API.
On Tue, May 27, 2014 at 11:52 AM, Cyrus Adkisson <cyru...@gmail.com> wrote:
I implemented getAuthToken and launchWebAuthFlow (I'm 90% sure) a while back and eventually reverted. I posted about the experience here:


Also, for a chrome extension, there is no redirect URL. The redirect goes to a default google/facebook page. Are you saying that launchWebAuthFlow will let me use a chrome-extension:// url?

On Tuesday, May 27, 2014 2:26:31 PM UTC-4, Jamie Walch wrote:
For the Google login case, have you looked into the identity API (https://developer.chrome.com/apps/identity)? It has a launchWebAuthFlow method which largely replaces the use of content scripts to do what you're trying to do. If you can't use that, consider including your extension id in the OAuth2 redirect URL and matching on it in your content script.
On Tue, May 27, 2014 at 11:21 AM, Cyrus Adkisson <cyru...@gmail.com> wrote:
It dawned on me today that my extension, which uses Google and FB for third party login, might conflict with other extensions doing the same thing.

For detailed information about how the login works, see http://blog.words4chrome.com/?p=54

The short version is that when the user authorizes my app via Google or FB, there is a redirection to a google or FB url where a "code" appears:


Via a content script, my extension grabs the "code" and completes the login. 

My question is, what would prevent other extensions from interfering? I'm not so concerned about possible malicious use of the code since it's worthless without my G/FB apps' secret keys... I'm more worried about other extensions listening on those URLs and executing scripts to read the code at the same time my extension does. Heck, my extension could potentially do that to THEIR login processes. 

How would one go about preventing these conflicts?


--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsubscribe...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.

Jamie Walch

unread,
May 29, 2014, 1:33:14 PM5/29/14
to Cyrus Adkisson, Chromium-extensions, cou...@chromium.org
Yes, I think removeCachedAuthToken is just for getAuthToken. AFAIK, for launchWebAuthFlow, it's up to the web page that starts the flow to provide some UI for switching accounts. Michael might be able to provide more insight.


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.
Message has been deleted

Cyrus Adkisson

unread,
Jun 3, 2014, 10:22:48 PM6/3/14
to chromium-...@chromium.org, cyru...@gmail.com, cou...@chromium.org
Thanks for your help on this. I was able to get it working and found that logging out + restarting browser *really* logs the user out. Not the best UI/UX, but it'll do. 

I think chrome.identity is having issues right now though. I'll post what I'm seeing in another thread right now.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/.
Reply all
Reply to author
Forward
0 new messages