This is a terrible idea that is full of security holes! If you can call having paper-thin pseudo security a hole.
Security holes such as? Please elaborate.
HelloJS – Client-side OAuth for JS
31–40 of 58 posts
Re: HelloJS – Client-side OAuth for JS
#32This is a terrible idea that is full of security holes! If you can call having paper-thin pseudo security a hole.
Security holes such as? Please elaborate.
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.
Re: HelloJS – Client-side OAuth for JS
#33Looks great. It's such a pain to write separate authentication / profile retrieval logic for each service.
Re: HelloJS – Client-side OAuth for JS
#34Earlier quoted context omitted.
Security holes such as? Please elaborate.
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.
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.
Re: HelloJS – Client-side OAuth for JS
#35Earlier quoted context omitted.
Security holes such as? Please elaborate.
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.
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?
Re: HelloJS – Client-side OAuth for JS
#36Earlier quoted context omitted.
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.
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?
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
Re: HelloJS – Client-side OAuth for JS
#37Earlier quoted context omitted.
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.
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.
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.
Re: HelloJS – Client-side OAuth for JS
#38Hmm, I don't see any mention of security. I can't find the source, but I remember reading that if you wanted to restrict access to certain pages on your site to authenticated users in a single page app it was more secure to do it server side. Security experts feel free to chime in.
> it was more secure to do it server side It's not it was more secure,it's that it is impossible to secure anything on the client(native or html,by the way) if there is no interaction with a server doing access control somehow. That one reason why old facebook app was downloading HTML instead of having it bundled and just requesting json payloads). What is a single page app? a single HTML file.How can you secure anyt…
Isn't the point of this not to secure some thing, as in "no access", but to sign something and trust it (i.e. a server signs a token and hands it off to another machine/app)?
If your point is "nothing is secure in the browser" then that includes the secured content sent down by a secure server no matter the method.
Re: HelloJS – Client-side OAuth for JS
#39Earlier quoted context omitted.
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?
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
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.
Re: HelloJS – Client-side OAuth for JS
#40Earlier quoted context omitted.
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.
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.
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.