I am looking to connect to a secure REST service via Angular and have found the official way to do this is to set the authentication ticket as follows:
$httpProvider.defaults.headers.common['Authorization'] = 'dhfkssksk';
However isn't this insecure as anyone can simply view the JavaScript and find out the auth code?
If you mean that your client app is connecting directly to your backend api (i.e. no 3rd party services), then the short answer is yes.
However, there are a few considerations you need to take into account:
You must only send this ticket to your backend and nothing else. I.e. set an HTTP filter in angular that acts on every client-side request and only sends this Auth header if the URL matches your API url.
You need to use SSL, to protect the token during transmission.
Related
I want to find a method how to share one token between multiple vue apps. With this i can create multiple single page application mimicking the microservices on back end. I was thinking about putting it into Vuex and save the state in localstorage/cache however i cannot retrieve the same state for another app. Any suggestions?
For such case using cookies would be appropriate.
Unlike localStorage, it is possible to share same cookie across parent domain (example.com) and subdomains (sub-domain.example.com). It is done by specifying domain property of cookies as wildcard - .example.com (note the leading dot in front of the domain name). Relevant answer
Depending on application architecture, you can manually read cookie in front-end on application startup, verify if user is singed in and save it to the store.
In case API is hosted on a subdomain as well, it is possible to make a request to the API (if cookies domain is specified, cookies header will be sent with a request) and verify if user is authorized to access the app. It is only suggested, if API doesn't check token in different way (e.g. in payload or Authorization header).
In both cases, it would be suggested to create API endpoint to verify token, call it on application mount and handle appropriately.
Also, since managing cookies manually may get quite uncomfortable, using third party libraries will provide similar API as using localStorage. For example: js-cookie.
I have client-side login on my app which is working just fine. Now I need to pass the clients UID to Node.
Found this Verify ID Tokens in Firebase docs, but i just don't know how would i actually do this part: "Send token to your backend via HTTPS"
Does your Node server-side piece have an API already created, or do you need to build that?
There are many ways to pass this information from the client to the server. Sometimes auth information is passed in an HTTP header of an API call that does something else. Sometimes APIs include a specific call to "register" a user with the backend, where you would pass the client-side token to the server in the payload of that one call.
There is no single best way to pass the client user authorization information to the server, every application needs to make that decision as part of their server-side design.
My Angular 2 application is behind a reverse proxy that add HTTP headers like:
Auth-User: somebody
Auth-Groups: something, something, ...
How can I read these values from my Angular 2 application? Note that I am not:
making a new http call,
doing a username/password login, add something to sessionStorage that I can use in a CanActivate
Basically I need to support a SSO scheme based on trusted HTTP headers from the very first time a browser hits my server.
Any ideas?
Lars
I realize that it cannot be done directly. Angular is client oriented and heavily sandboxed by the browser, so it is only the server that is able to access the necessary headers. What I have come up with is:
get some user settings service on the server. Includes the user and groups information the response. Service calls to the server cannot of course trust the client's view on who is the current user and group membership. The is the one I chose
Use Universal Angular, which is server side oriented. In my case it didn't fit the culture of the company.
So instead of doing a basic authentication scheme like most examples/tutorials use, the solution is just getting the headers values wrapped in a service call.
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 building an API and had questions about handling authentication when using a front-end framework such as Backbone.js.
I have a single API server that is responsible for returning and modifying data based on RESTful web requests.
I have another app server that is a Backbone application. I want this application to connect directly with my API server, so set the entire project up so that this app server can make cross-domain AJAX requests to the API server.
There are some API routes that I do not want unauthorized parties to obtain access to. For example, I have a path /users that lists all the users of my app. I need this path later on for admin functions, but I don't want it publicly available to my app server.
What is a good authentication scheme to use? OAuth won't work because the secret token would be exposed on the front-end. And after that, I'm a little stuck with what my options are. Does anyone have any suggestions moving forward?
In cases like these I use a combination of techniques.
-- Good ole Cookie based auth
As a backbone app will always be used inside a browser and browsers have built-in cookie support, I would suggest that you should accept cookie based sessions on the server side. All the auth related stuff will be handled by the browser and you don't have to worry about storing keys etc. On top many libraries like (NSURL in iPhone) and frameworks (like PhoneGap/Trigger) all support cookies so woha you can support all kind of clients with litte work.
-- Plain API Key
For third-parties, I use api-key based authentication. You provide username and password, I provide key. You send me that key every time in HTTP header for all subsequent requests. I use the key to identify you and then allow/disallow actions accordingly.
I assume once you can authenticate a user (wait..who are you?), then you can setup authorizations ( you say Micheal ? ...ok you can access /users )
Also take a look at my backbone-parse plugin for an idea on how to authenticate users against an external API service #shamelessplug