I have separated projects,
Server side node.js with express to serve restful api but returning JSON instead html. All the examples in internet are returning html with ejs.
Frontend is and independent application with backbone and socket.io.
I want to do a login and registration page and I did it with passport.js on the server side, but I have not idea of how to send the token to the frontend and store it there to send It on every request to the server. If the user is out of session then the login page, ,must be shown.
I want a way compatible with oauth 2.0 for multiple authentication strategies.
Sorry for my English and I have a lot of dudes and I don't understand all the concepts.
Basically what you have is an API and a client, and you need two things:
The client to be able to open a session on the API.
The client to be able to embed its session credentials in every request so that the API knows who is doing the query.
First Step
For opening the session, you have figured it out: you want your API to be an Oauth Client.
So when a user wants to log in, your client will redirect it to http://api.yourserver.com/login/google which will redirect to google, which will redirect again to your API with a token that allow your API to access Google's API (hence, know who your user is).
This token cannot be used to authenticate against your API. Its only goal is to allow your API to act on the user's behalf on google services.
Second Step
Then you need to decide how will your client authenticate against your API. You can choose to use a cookie which almost everyone do (it's the sane default for express sessions).
Or, if your API is consumed by many different clients, and you don't have control over those clients, you can choose to implement an Oauth Server to protect your API.
The clients will then authenticate against your API using a "Bearer Token" (it's an HTTP header).
Related
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.
we are writing a web application on .NET MVC.
It has a textbox and when a user types 'H' we must display all businesses that Yelp thinks are relevant to 'H' (Hotels, Homedepot, etc..)
We are using Yelp Search API 2.0 as described here
A standard solution would be to send AJAX request to our server which pulls the access token and other credentials from our database and sends requests to Yelp server using Yelp client here, then send the result back to our client.
We can do that. What we would like is to bypass our home server and send OAuth-ed requesed directly to Yelp. I found a solution for this here (their example is here index.html)
If we want to pursue this path, we would generate an MVC View in our app that would contain all credential data (access tokens, etc) and use OAuth.js and SHA1.js libraries.
My undesratanding is that it is not a great idea to expose one's credentials like secrets and tokens in a plain view on the client side (this is specifically states on line 15 of the example).
My question is, how can I conseal this secret information and if it is possible at all for all request to be sent directly to Yelp bypassing our home servers.
I'm developing a backend service in Grails that should serve both a web application and a mobile application.
The frontend is being developed using AngularJS and the mobile app will use the same AngularJS codebase to go native with PhoneGap.
Now, I'm looking for a proper way to implement the authentication with the Grails backend that works both for the web app and mobile app.
Three ideas:
1) Store username and password in LocalStorage and authenticate the user on the backend at every request
2) Use cookie based authentication (it's tricky to enable cookies in PhoneGap, I should
extract from the AJAX response and attach in the AJAX request)
3) Develop a custom protocol that generates a token for every session in the backend and stores that in LocalStorage. The session token will be sent in every request to the backend.
4) Sign every request using a private/public key mechanism (similar to Amazon AWS). Even in this case, the backend has to verify the correctness of the signature for every request (there is not a session concept).
I don't trust the LocalStorage so much but I have no other ideas and I can't find any example (an example with other backend and frontend technologies would help the same).
You can assume that the backend will run on HTTPS.
I would go for the third one, with some additions:
The first time the device is connected, you authenticate the user in some way (user/password or whatever). Then you send a persistence token to the device which saves that to the LocalStorage.
For each following session, upon opening the client exchanges the persistence token for a short lived session token (how much short lived is up to you, depending on the context).
This is similar for what you provide but reduces risks of man-in-the-middle and replay attacks.
Hope this help!
The Problem:
Serving a secure API to a client side app using only a local authentication strategy. The red arrows are part of the knowledge gap.
Context:
That is --- client.example.com is making a POST to api.example.com/login where on success client.example.com can gain access to a GET service like api.example.com/secret.
An idea!
Implimentation of OAuth 2.0 with hybrid grant type sitting in front of API.
Why hybrid?
It wouldn't be an Implicit Grant Flow aka Client-Side Web Applications Flow because there is no redirection to API server too grant access token. (i.e.) "Is it ok for so-and-so to access your data?"
It wouldn't be a Resource Owner Password Flow because a Client ID and Client Secret are passed along with the request so it's assumed the client app is server-side.
OK... so what about a little bit of both?
What if we used a CRSF token on page load of client-side app, and POST it with user credentials too OAuth 2.0 authentication endpoint to exchange for access token? You would authenticate each subsequent request with the access token and CRSF token after a successful login.
A good Node.js OAuth 2.0 library I found:
https://github.com/ammmir/node-oauth2-provider
Help Me!
I can not find a working example of an authentication measure that solves this problem! Point me in the right direction?
Ultimately, the goal here is too authenticate a client side app to a REST api using CORS with a local strategy --- i.e. username & password --- even if the convention above isn't possible.
To Accommodate Bounty:
This is a client side app, so let's stay trendy.
I'm looking for a working example using the Node.js OAuth 2.0 seed above for the API/Auth server and a front end framework like Angular.js or Backbone.js to make requests.
The example should match the context described above.
I'm working on an app with a pretty similar architecture though the services are .NET Web API rather than Node and we're using DotNetOpenAuth for the OAuth provider. Rather than the hybrid approach you're suggesting we're doing the following:
x.com serves up a login page
login page POSTs back credentials to x.com
server side logic at x.com combines client_id and client_secret with the credentials to submit a token request (resource owner password credentials grant that you've
mentioned above) receiving back both a temporary access token and a
refresh token
the refresh token is encrypted into a cookie issued by x.com
both the cookie (with encrypted refresh token) and the temporary access token are then sent to the browser
the client app (angular in my case) can now use the access token to hit api.x.com for services (It appears you're well aware of the limitations of CORS... we hacked a version of angular's $resource to facilitate this but it wasn't pretty since we wanted to use all HTTP verbs and support IE9)
when the access token expires, the client side app can request a new access token from x.com
server-side, x.com decrypts the cookie to get at the refresh token and issues another oauth call for a new access token
This is fairly high-level but hopefully gives you a sense for how to tackle your situation. In my case, and it appears in yours, we didn't want to use session state or a database to store the refresh token but obviously exposing that to the browser introduces security concerns so the encryption of the refresh token is important (among other security considerations) and the use of the cookie eliminates the need for session state or other persistent storage on x.com.
Not an answer running for the prize. Just my 2 cents :)
On my web server,
I do my authentication through a rest call with login/password with basic authentication over https. This call delivers a key to the client (a one page web app).
Then every subsequent REST call is signed with the key. The server checks that the signature is correct and everything still happen in https.
This mechanism is quite used I believe.
I don't see the issue with cross domain. I have a single source anf if I need something from another source, I'd use JSONP.
I use nginx as an https->http forwarder.
Not sure how it competes with an OAuth2 solution.
I've built this example using Node and PassportJS to show how to authenticate the users with Facebook or Local Strategy. Both sides are on different domains as you described and it requires CORS enabled.
GitHub: https://github.com/pablodenadai/Corsnection
Live demo: http://corsnection-client.herokuapp.com/
I can't promise that I have time to write working example but I can show you 2 paths :)
The biggest deal is CORS. After you solve that problem it is easy to use $http service. So, first and probably easiest may be to configure reverse proxy in x.com webserver which points to api.x.com. I wrote article here
Second approach is better, and created for exactly this purpose, to authorise specific domain to use your resource. It involves a bit of coding in api.x.com so you don't have to change anything in new web applications served in other domains. You simply need to authorise CORS requests in api.x.com service.
Create table in database where you can manage list of authorised domains
Add in that table record "x.com"
in api.x.com add request filter/interceptor what ever tech term you use for method which should be invoked after request is handled and add in response Access-Control-Allow-Origin: x.com if request comes from x.com (in other words check in request header refer value match to any value in table above and put that value in Access-Control-Allow-Origin response header).
That is all :) After this if you know how to use $http or jQuey.ajax you will be able to POST/PUT/DELETE/... any request to api.x.com from any authorised domain in just few minutes.
I very similar idea using vinilla js web app and cross domain authentication to GAE backend or OpenID connect.
The web app is run on CDN. When click login link, it goes to respective login server and redirect back to the web app (with XSRF security token and HTTPS only cookie). Login server accept cross domain request with credentials. XSRF token has to be set (in header) with every request. cookie is set by the browser. Since it is HTTP only cookie, JS cannot read it. The technique is very secure.
Once login, you can get secure assess from login server.
For detail description, you can find here and open source repo here.
I am developing an open source javascript project. It has client side database, Oauth Connect login and bear-token base access to cross domain resource servers like (GData, Google cloud storage, AWS via proxy). The main focus is on consumer cloud data (you know, developer got free data storage).
The main goal to provide database to the web app without using backend server. It is achieved by keeping Oauth 2 refresh token in the server, providing access token to the web app so that it can populate its client side database, directly from resource servers. Dumb proxy server may be necessary for updating back to the resource server.
Login user may share his data to other login user. Server provides access token as necessary. In that case I wish to down-grade the access token. Generally once a new user start using the app, the server request off-line multiple scopes read-write grant. Currently, I as far I can understand a refresh token can generate access token of exact scopes.
Is that possible to request a down-graded access token from an offline refresh token? Even down grading from read-write to read-only is very useful.