I'm looking at the oauth implementation twitter proposes here:
https://dev.twitter.com/docs/auth/oauth
and oauth libraries like signpost:
http://code.google.com/p/oauth-signpost/
they both talk about using the client secret during the oauth flow, which means for my client application, I'd need to store the secret in the application itself. This is probably risky as someone could grab the secret out of my app. Are there any methods around storing the secret within my app? Am I misunderstanding the oauth flow?
Thanks
There are no ways of storing client credentials in a native or JavaScript application without making them practically public. Also, putting those credentials on a proxy server and having the client talk to the server (so that the credentials are not exposed) doesn't really solve anything either. Now you have a problem of authenticating the client to the proxy.
The right solution is to have special support for native applications provided by the OAuth service. OAuth 2.0 uses pre-registered redirection URIs and other techniques to accomplish a reasonable client identity verification for such clients.
Related
I'm building an App which I use ReactJS to build my Client-side and Spring framework for my Server-side setup. What I'm trying to archive is a way to store my ClientId, Client secret and OAuth token since I'm implementing OAuth2 Security on my Server-side
I've been searching for the solution for awhile and here is what I've gotten so far
Using local/session storage
Use a Proxy server
The second solution sounds really good for me since the client side won't ever have to know anything about it's id or secret registered with the Authentication server but what I makes me think about is the efficiency of this flow. Will this approach slows down the App since you have to 'proxy' the requests?
Can you use the server side code to store the information as well? Then you don't need a second server to act as proxy, nor do you have to store it with the client.
I'm building an Node API, together with a Javascript client Application.
I was wondering if there are benefits to implementing OAuth, if I am also using HTTPS.
What if I just send username + password on each request instead of implement OAuth?
As far as I know, HTTPS encrypt the client-server communcation. But I might be missing something importatn.
I'm not going to allow third-party apps to access my API.
OAuth is authorization framework, so you are not getting any security over your API calls by default, especially if you are using OAuth2 which is most likely the case. If you don't need to authorize third party apps, then you don't need it.
If you want to secure your API though, then take a look at hawk, using just Basic authentication is a bit naive.
I am developing an app using node.js which will also have an mobile client. I am looking to make the authentication using OAuth 2.0. Is there any good module which allows me to have OAuth 2.0 authentication server?
I looked at a subsidiary module of Passport "OAuth2orize". I found it quite good enough, but the real problem was understanding how it will work for my own app (the example and docs specify about third party authorisation).
Basically what I want is that the client logs in with client id, user's username, user's password and there by I hand him a token after verifying the above 3 things. But the problem with Oauth2orize is that there there are redirect URI and all which is confusing me a lot.
Please help me know as to how can i achieve this using Oauth2rize or any other really good module. Or If its easy enough I can also roll my own, but will that be a good idea regarding security ??
What you are looking for is the Resource Owner Password Credentials flow. As you've seen, the examples for oauth2 do not include functionality that supports this flow. In fact the examples only cover the Authorization Code flow.
It should end up being fairly easy to implement. All you need to do is accept a request that contains the information you are looking for (and authorize it) and create a token in your token database and return it. As long as you use the same token database that the rest of oauth2orize is using, it should work just fine. See: Passing Trusted Client Information with oAuth2orize for the "Resource Owner Password Flow" where that is exactly what is suggested.
Correction:
The all-grants example of oauth2orize supports the Implicit flow as well as Authorization Code flow.
Background: I am using node.js and express to create an API. I have implemented OAuth in my API server in a standard consumer/user key/secret fashion (the same way Twitter, Facebook, etc. do). I expect 3rd parties to connect to my API, again in the same manner as these common APIs.
Normally, a client would connect with an application token/secret (eg, you create a Facebook app as a Facebook developer and these are given to you). However there are times when the client cannot provide a secret for the application because the code is implemented in an insecure fashion. Specifically, I am referring to Javascript libraries. Eg, developers do not want to expose their application secret in Javascript code because it is plaintext and could be read by malicious users.
I've noticed that Facebook avoided this problem. The developer needs to provide only an application token (not secret) to the Javascript library. I do not understand how to provide a similar option for my API without fundamentally making my library insecure. Namely, if requests are being made by a Javascript client library to an API without providing a well-secured token/secret, how are those requests authenticated by the OAuth API?
Intellectually, the best solution I could think of would to have some sort of token handoff between the Javascript client library and the API server via a HTTPS connection, in order to return a secret for the library to use. I'm not quite sure how I'd secure this handoff to prevent spoofs, though.
In most cases it is better to follow the standards than to implement some custom way. OAuth2 specifies 4 methods in the latest draft (28) to do the Authorization Grant flow. The implicit flow is the one you saw on Facebook.
As the standard says for that:
When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent.
Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application) since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, especially when the authorization code grant type is available.
it has some security drawbacks.
But as far as I can see, the other methods don't work for you, as they are exposing secrets to either the client (third-party website owner) or the resource owner (user), so you should stay with this.
I have a node.js API that I want to protect via 2-legged OAuth. Was wondering if anyone knows of a server side implementation for this. Please note that this is for server to server communication and is not to provide user authentication via a 3rd party server.
Take a look at passport-http-oauth, a Passport authentication strategy. It implements the OAuth HTTP authorization scheme, and can be used independently of the user authorization flow (as is the case with 2-legged OAuth).