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).
Related
I am planning to deploy a separate resource server and an authorisation server, both running on django oauth toolkit. Assuming that the clients or the applications using our API services are in the same organization, and will host their frontend to use our APIs, and the users will be logged in on their side and we just have to authorize those clients (that are running the application).
Which Grant Type Should I use?
RFC 7636: Proof Key for Code Exchange
PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks.
PKCE is not a replacement for a client secret, and PKCE is recommended even if a client is using a client secret.
Note: Because PKCE is not a replacement for client authentication, it does not allow treating a public client as a confidential client.
PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use a client secret.
I have a web application in node js that consumes an API for certain aspects of the content of the website e.g news. The API is written in node.js and points to a mongodb database.
I would like some advice as to the best authorization strategy for this type of requirement. I don't really need a user-name and password solution (I don't think). Some sort of static token that the web app can pass to the API so that only applications that have this token can browse the data returned by the API. I mainly want to stop just any old application consuming the API.
Here is best blog that can help you how to authenticate the REST Api in node js with the help of Basic HTTP Authentication, Oauth1 And Oauth2
https://stormpath.com/blog/secure-your-rest-api-right-way
Basically there are the three type of authentication that generally used
Basic Authentication
Oauth1.0a
Oauth2
Http Basic Authentication
More convenient, as you can easily expire or regenerate tokens
without affecting the user's account password.
If compromised, vulnerability limited to API, not the user's master
account
You can have multiple keys per account (e.g. users can have "test"
and "production" keys side by side.)
Oauth1
OAuth 1.0 requires client to send two security tokens for each API call, and use both to generate the signature. It requires the protected resources endpoints have access to the client credentials in order to validate the request.
Oauth2
OAuth 2.0 signatures are not required for the actual API calls once the token has been generated. It has only one security token.
Here describes the difference between OAuth 1.0 and 2.0 and how both.
i'm building a web Api with node.js and a client to consume the service with Ember.js. This client is considered to be "The Official" as the service is intended to be consumed also by third parties (like twitter, facebook, g+, does).
My concern is the security of the API.
The approach i'm trying to accomplish is to implement oauth 2.0 with the oauth2orize module to give access to every registered client the user authorises. The problem with this is the user would have to authorise the official client too, like it was a third party client. I want the authorization to be transparent to the users login into the official client.
Is there a way to avoid the authorization or give it automatically to the official client for every registered user?
Is this the best approach?. My other idea is to use basic (user:password:cookies) authentication for the official client and leave the authorization part only for third parties. In that case, how would i know if a request is coming from a third party or the official client to use the proper authorization schema?
thanks in advance.
Which of the authentication methods above is considered to be better and why? The purpose could be for performing a GET/POST request.
One major benefit is that OAuth works a bit like a valet key - you can authorize an app to work on your behalf without giving it your personal password, you can revoke its access without having to change your own password, etc.
http authentication is not encrypted. Oauth uses an authentication server to securely log in over https therefore it is more secure.
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.