[1337badger]

From what I gather you are leaving the api_tokens for the services in local memory. This means that the user or anyone else that can get there hands on the token can act on the service providers api masquerading as your application.

[heme]

Is not a session cookie the same thing? I'd argue if your tokens only live in memory they can be more secure. It also depends how long your tokens live or how many requests they are good for. No?

[1337badger]

Usually the token kept in memory is one distributed by the application and is not that which the services send back. This allows greater restriction on actions and make it far easier to revoke effectively

[heme]

Usually the token kept in memory is one distributed by the application and is not that which the services send back.

What is application in that sentence? The API?

Isn't that what this lib does?

A client-side Javascript SDK for authenticating with OAuth2 web services and querying their REST API's.

- I assume the API issues the token - This lib receives it and uses it for subsequent calls - The token is destroyed when browser session is closed.

[1337badger]

I am referring to the application you are writing

[tracker1]

The token in this case is for the local user, that you know, logged into the service in question... How is it insecure for my browser, with me in front of it, to be logged into facebook? I mean, yes, if you're using anything other than a session cookie or sessionStorage, there's risk from other users on the system... but with an SPA, without any hard storage, it's no less secure than using that site/app.

[pluma]

It only has the `client_id` on the page. The `client_secret` is not disclosed to the user, although using it apparently requires using the "OAuth proxy".

I'm baffled this actually works. The entire idea is that the `client_id` can be disclosed to the user (via the login redirect) because the `client_secret` is required to verify the application's identity.

[bikamonki]

Well, assuming that the front-end app is served through SSL (avoid MITM), the only other possible hole I see is physical access to the machine while the browser tab is open, no? Can other browser tabs, malware or browser plugins access memory while the app is running?

[taylorbuley]

Session store is a good place for these, purges on browser close. Or logout, and those api_tokens are no longer valid. To me, lightweight, throwaway tokens seems exactly the purpose of oAuth.

[1337badger]

It really depends, it will purge on browser close yes but it still allows access that make not have been intended by your application for use by others also the refresh token may also be stored. The danger is in someone getting this token from an active session and using it outside of its intended parameters not the normal use case.

[heme]

Not doubting you, but I would love to see the methods to make this happen. Is your concern from a 3rd party script included on the page?

From my experience memory is safe between origins in the same way cookies are. And it is the dev's responsibility to not do something stupid with the token like window.FacebookToken = OAuthToken;. But that holds for traditional session cookies as well.