My client is web based with a NodeJS server.
I've recently implemented Google Sign-In for server-side apps using this flow
see https://developers.google.com/identity/sign-in/web/server-side-flow
I'm now trying to implement something similar on Facebook but when I look at the docs there is no reference to oauth2.
https://developers.facebook.com/docs/facebook-login
Should I be using Facebook connect? Where do I get my "one time code" from so that I can send it to my server?
Lots of confusion on the subject. Some direction would be most welcome.
OAuth is, by design, not a very prescriptive standard. It describes various flows for doing the authorization, and each of those is specified broadly enough to afford multiple interpretations and implementations.
Facebook's implementation is broadly similar to Google's, and supports many different flows. The Javascript SDK offers a way of doing it in the browser, whereas the more traditional server-side flow uses a series of redirects and doesn't require any Javascript. Neither Facebook flow really calls itself OAuth, though the latter refers to it implicitly.
You asked about a "one-time code". That's a part of the Authorization Code flow described in section 4.1 of the OAuth2 specification. The server-side Facebook flow described above seems to be quite close to the specification, and the documentation describes how to get this code and exchange it for an access token. You could do it using the redirects, or you could write some Javascript to hit that endpoint in an XHR and then extract the code yourself and pass it to the server.
But you could also use the Javascript SDK to do essentially the same thing. It is based around the Implicit, browser-driven flow described in section 4.2 of the specification. In that case, the client is issued a short-lived access token. However, it can send that token to the server, and the server can then exchange it for a long-lived access token, similar to the use case of the one-time code. That process is described in the Javascript SDK documentation.
All of this is to say that I wouldn't worry too much about what is or isn't "OAuth". Most of these authorization services are based on the same basic OAuth concepts, but because the specification is quite general none of them work exactly the same way. Just figure out which flow works best for your application and use that.
Related
From the official tutorials on https://community.algolia.com/instantsearch.js/, Algolia requires you to code the key into your application and used with each api request. If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
If someone were to dig this up, what's to prevent them from spamming search requests with your api key?
Do you want the cruel truth? Nothing...
Unfortunately in a web app does not exist anyway of securing secrets, be they api-keys, tokens or any other name convention that may be used.
In a web app all is needed is to use F12 or view the page source and search for them in the raw html and JavaScript.
You can try to use JavaScript obfuscation to make it hard to find but will still be easy to reverse engineer. Even in a mobile app that have their code obfuscated and released as a binary is easy to extract this secrets.
If you want to understand a little more about Mobile Api Security Techinques please read this series of articles to find how api-keys, access tokens, HMAC and other techniques can be used and bypassed. While the article was wrote in the context of a mobile API is still valid in a web app context for the security techniques used to protect the API.
Possible Solution
The best approach is to always delegate your web app access to third part API's to a backend you can control.
In this backend you can then use a User Behaviour Analytics(UBA) solution to monitor bad use of this third part access.
Once UBA can be complex and expensive to deploy you could start by using the new Google reCaptcha V3 across all pages of your web app. ReCaptcha V3 does not require direct user interaction once it works on the background to differentiate humans from bots.
So I would have the web app requesting the Agolia search to my backend that would use reCaptcha V3 protection to differentiate abuse in the search functionality by bots or attackers.
Remember that this approach has the huge benefit of never reveal your Agolia API Key, thus attackers can never directly use it.
In my current work, I have to develop an intern REST API engine.
I have read the Roy Fielding thesis, documented myself, and I finally got something that works great easy to use, with high performance, corresponding to the Fielding REST spec.
There is only one point that I dont really know how to overcome : the security problem.
Again, I documented myself, and I wanted to use OAuth2.0 in my engine.
The problem is that I dont understand nothing at all how to use this protocol.
I dont understand how the consumer can connect himself and be recognized by the server.
I dont understand if I have to provide API key to my consumer(like Facebook, Twitter and Google make it) or if a token will automatically be generated if I send a login / password to the server
I dont know if I have to create my own OAuth2.0 server that provides keys, or if OAuth2.0 libraries are sufficient to provide security.
In fact, I dont understand nothing at all with OAuth2.0, and I need to learn. The problem is, every documentation that I try to read is like chinese, I didn't find an easy one, step by step that will help me with this.
That's why I post here, can you help me understanding a bit more OAuth2.0 and the secured authentication for API ?
I willingly didn't speak about the technologies, because I want to understand OAuth2.0 before applying it technically.
Thanks for all
The main problem with OAuth (both versions) is that you'll see a lot of talk about the three legged version. That is when you have user, a data-providing service and a consuming service, let's say a service that will create physical copies of your flickr photos. In this case the OAuth flow allows the user to tell flickr that the third party can access their data. This is not the scenario you are after, you are interested in 2-legged OAuth, see here for a description.
Of course you could look at other methods too. I've used HAWK in a number of REST/Hypermedia APIs and found it to be great to use in both nodejs and .NET server stacks.
Thank you for your answer, I studied a bit more OAUth2 en tried to implement it with 3 stragery : basic, clientPassword, bearer.
I created a new thread for an other problem, if you want to take part of it :
OAuth2 server creation with nodejs
I am a total noob in Scala, I am just learning. So I am writing a server in Scala and I need to login to Github to access a repository. Are there any libraries that implement an OAuth consumer that I could use? I come from Ruby, and there is Warden that I used in the past. I am looking for something like that...
There are two versions of OAuth, OAuth 1 and OAuth 2. Github uses OAuth 2. The Play Framework authors, for one, consider OAuth 2 sufficiently simple to implement yourself that they don't provide a helper for it.
However, Google says:
"Given the security implications of getting the implementation correct, we strongly encourage developers to use OAuth 2.0 libraries when interacting with Google's OAuth 2.0 endpoints"
(I know Github isn't a Google endpoint, but this security point is valid for any website protected by OAuth.) And Google provides a generic OAuth 2 client for Java, and because Java code can be called from Scala, you can use that.
However, note that certain Github API calls (I think it's ones that access public repositories) don't require any authentication.
You will, however, need to set the User-Agent header to the name of your application in each HTTP request.
Based on the question I asked here, but I wanted to get feedback from the stackoverflow community on this.
It seems from my tests using the twitter API with oauth that oauth_verifier check that should be done by the service provider (twitter) in step E of http://oauth.net/core/diagram.png is not being done by api.twitter.com; this happens whether the oauth_callback is oob or a regular callback url.
To test this on twitter is simple: just don't send the oauth_verifier parameter as part of step F for acquiring an access token.
This issue should be easy to reproduce, but if necessary I can post my test code.
The oauth_verifier was part of the solution to the session fixation threat, and was only introduced in the oauth 1.0a specification. Because of this twitter API may still not be forcing application developers to use it to avoid breaking backwards compatibility.
Is this correct? Or am I misinterpreting the oauth specification?
Does this also happen with other APIs that should be compliant with oauth1.0a? (LinkedIn etc..)
ps - This question is somewhat related but the issue no longer applies because twitter is returning the oauth_verifier for both types of callbacks (oob and regular callbacks).
I got a reply from the official twitter discussions:
Currently the API supports both the OAuth 1.0 and OAuth 1.0a authorization flows. We strongly encourage developers not using OAuth 1.0a to update their code as soon as possible.
I've seen many questions about restful-authentication but I'm wondering what strategies are being used to keep browser user agents stateless while authenticating to a RESTful web-service.
Doing it with a custom REST Client is "easy": We can use Basic Auth, Digest, OAuth or roll your own (custom headers, tokens, signatures etc). Thus, for machine to machine we are pretty much covered but I'm only interested in authentication with everyday browser user agents (IE, Firefox etc). For example JSON is out since the browser can not render / use it ;)
Here are some of my thoughts in terms of browser limitations:
AFAICS there is no way for a browser to send custom headers such as those used by OAuth? (Right?)
I have a feeling that one should be able to have a login page (html+ssl for example) where the user does a login. (No Basic auth) The browser then captures a token(s) and passes it back the server with each request. The problem I have with Basic Auth is that I do not have a “nice custom login page”. Is the current authentication mechanism to extensible that we can keep it restful?
I'm careful in breaking / relaxing REST constraints because of the risk of loosing the benefits of scalability.
A similar answer here but I have a special case against cookies : (without going to much detail): The way browsers currently work in using cookies is out of the question since the server is in control of the cookies. ("Set-Cookie" header from server side state). The client does not understand or interpret the contents of cookies it's fed and just returns it. The problems is that the client is not in control of the cookie. Thus, yes we can use cookies in a restful way in "custom/machine to machine clients" but it's not the way browsers implements it.
What strategies and best practices are there that you have been using and what are your experiences? Any extra comments?
I think the browser limitations you mention are essentially insurmountable for most use cases. Our personal solution is to have a lightweight non-RESTful layer presented to the user which contains a custom REST client; for example, for JavaScript apps we expose a server-side REST client via JSON-RPC.
If you are using an apache web server, you might want to take a look at this document.