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.
Related
I have seen across all blogs and articles is that there is two ways to handle JWTtokens, put them inside localStorage which subjected for XSS attack or put them inside Cookies and set httpOnly and secure flags to avoid XSS.
Using localStorage
For every request to the server you extract the token out of the localStorage and append it to Authorization : Bearer <Token> manually.
Using Cookies
It is handled server side since it won't be accessed by JS client side, what you do is res.cookies(token), and it is going to be sent automatically for every subsequent call unlike localStorage
But lately i saw some developers simply put the token in the headers using res.headers('x-auth', token).
Is it a third way to handle JWT?
Would the X-Auth header set for every subsequent request to the server like cookies automatically or you have to set it manually (like in case of localStorage) ?
Are tokens in X-Auth header cannot be accessed by JS and secure like cookies?
what is the difference between doing it your way res.header('X-auth') and res.cookie(token) ?
Finally what is the best way to do it if my API is consumed by by ReactJS web app and react-native mobile application?
Thanks
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.
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.
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
I'm building an application with Ruby on Rails. The application is a Javascript application that get data by JSON calls from the api application. It also provide the cross domain authentication for the application itself and the api.
I handle the cross domain authentication via making both application cookies with same secret session key and same name e.g. _app_an_api_session.
Now, I'll write down the senario and I'll show you when it fails.
The application domain is domain.local the api domain api.domain.local
Lets say that api.domain.local/me is a protected page. When I open it i got unauthenticated
When I go to the application and sign in and go to api.domain.local/me again, I can see the data in it. [Pass] [it works also for the opposite actions].
The problem is, for example, after sign in I want to load api.domain.local/me contents [JSON data] in domain.local, I can see in the console that the status is (canceled).
In addition for debugging sake. I tried to see the env variable on each request to the api. So, when I access the api.domain.local/medirectly, I can see the cookies hash in the console, else if it via the real application, there's no cookies/sessions at all.
So, how to make it possible to done this right?
Your issue is the Same-Origin Policy that prevents communication between different domains and subdomains. You can resolve this either through using a proxy, JSON-P or an external proxy.