To summarize, we are using Vue on the front-end and Hapi JS on the back-end. The front end uses MSAL.js to authenticate users and then passes an access token to the back-end. The access token is decoded with hapi-auth-jwt2 and the validate() function returns { isValid: true, credentials : { ps_ref: 12345, md_userid: asfasgsg#5874.com }}. This object is then passed to the handler function of a route which extracts authentication groups/user roles (i.e.Auids) from our DB and user data and returns that.
Imagine that the user object looks like this:
{
Auids: (4) ["user", "webadmin", "accounts"]
md_clock: 5678
md_picture: "./images/"
ps_fname1: "Test Name"
ps_surname: "Test Surname"
psname: "Test Name Test Surname"
psref: 125125
}
Now, we would like to store this object in Vuex, however, we are concerned that it will be visible to anybody who has installed the Vue Devtools in their browser or anybody who executes something like rootElementOfApp.__vue__.$store
Our questions are:
How easy it is for somebody to access the Vuex in production?
If it is easy enough to access Vuex by the public, is Vuex the best way to store this object? If we go for Vuex should we encode the user object or at least the Auids in it ?
Everything you store in the js/html/cookies is not save on it's own. But it is all related how you will manage it. Basically you can store almost everything in the front end, as long it isn't sensitive data that's usable for ethical hacking. Things like addresses, contract numbers, bank accounts etc.
Data like userIds (as long only used for programmatic reasons) or a user roles can be stored in the front end. But if you do it right you always have every client side validation also in your back-end application.
In terms of dev tools of vue they are only available in development mode not production. But a good hacker doesn't mind.
Related
I want to implement authorization layer on my microservices project. I have 3 microservices customer-service, workspace-service and cloud-service. So if a customer want to create a cloud instance he will create on behalf of a workspace which means that the cloud instance will belong to the workspace instead of him and also he may invite other customer to the workspace, and have access to the cloud instance. The data structure may looks like this.
// workspace
{
"workspaceId": "ws-123",
"customers": ["customer-123", "customer-456"]
}
// cloud-instance
{
"cloudId": "cloud-123",
"workspaceId: "ws-123"
}
I want to implement authorization logic that check if a user has access to a particular cloud instance. In order to do that I need to have workspaceId somewhere else in my authentication object. One thing that I can think of is that to put workspaceId in the jwt claims so my jwt may looks like this.
header.{ ..., workspaceId: ["ws-123"] }.signature
but the drawback of this solution is that the workspaceId claim won't be updated until the token has been refresh.
another solution that is to implement a service that query data from workspace-service and use it to validate.
const hasAccess = (customerId, workspaceId_on_cloud_instance) => {
let actual_workspaceId_that_he_has = workspace_service_exposed_api.findWorkspaceByCustomerId(customerId)
return actual_workspaceId_that_he_has == workspaceId_on_cloud_instance
}
but this approach would heavily rely on workspace-service if workspace-service is down then the other service can not handle a request at all since it doesn't have access to workspaceId.
So IMHO I would rather go for the 1st option since I use oauth2.0 and token will be refresh every 30s, but is it bad practice to do that? I wonder if there's better solution.
Having 3 microservices you cannot implement functionality with assumption that one service is down. I have feeling that access token lifespan is also defined based on this restriction - to have up to date data in the token. As I correctly understand, in worst case there is also ~30 sec. delay related to workspaceId update in token payload.
Token claim will change only when you invite or remove person from workspace so this service must work anyway. I would use 2nd solution with longer token lifespan to not generate it so often.
Another solution is to generate new token every time when workspace is changed - you can treat adding/removing to workspace as a business logic that invalidates token, but probably in this case communication to workspace service is also required.
If you are afraid that microservice will be down or you will have problem with communication, maybe you should focus more on app infrastructure or choose a new solution based on monolith application.
And back to question from title - adding any custom claim to token payload is standard approach.
This is something more likely as conception question. I am doing the Front-End of website and there is already created Back-end from another person. One of his endpoints is "Login endpoint" which sends me in reply several stuff:
Token (JWT)
UserId
Name
Address
Company
(and some others)
I receive all of them directly after login as response. So I am wondering which is the best way to save them? As we can assume it will not be a problem to save everything except Token in localStorage or in cookie with js-cookies package but how to store a token? It is unsafe to be stored both in local/session storage and in cookie. Currently I have Auth context which stores all of this:
import React from "react";
export default React.createContext({
token: null,
userId: null,
address: null,
firstName: null,
lastName: null,
email: null,
company: null,
subscription: null,
login: (token, guid) => {},
logout: () => {},
});
After login I pass it in
<AuthApi.Provider
value={{
token,
guid,
login,
logout,
address,
firstName,
lastName,
email,
company,
subscription,
}}
>
In the App.js so they are accessible from all components inside the project with useContext.
As you know, when browser is refreshed we lost all the values. So basically here I don't store the values and Token also in cookie or local/session storage but I loose it after refresh. What is the best solution here if I cannot make changes in the back-end?
If you want to be able to revoke the token at any moment you can store it in Redis.
Its faster than querying the DB everytime so its a good compromise.
you can check this answer for more details Should I store JWT tokens in redis?
Your question is too generalist and can't be answered without knowing about these details
Questions to consider
Does the front end communicate with different domains or servers?
Based on the token are you doing any job in the front end? (eg: managing states like isLoggedIn). Remember other data can be cached in local storage and can be used stale while revalidate technique.
Does the token will be expired if something like a role or name or anything else changes? (eg Custom claim in firebase is a typical example of it)
Does your server has control over the authorisation server or you are using a third-party server like okta, firebase or something else? (if third party its ok to go with their recommendation unless you know what you are doing)
If you disable an account in the backend how will the front end know and logout? (long-lived app includes electron or a browser extension or native app or in my case youtube which I don't remember when I closed previously)
One last note
Cookies are more powerful than you think. For XSS attacks enable HTTPS only. But that's just the tip of the mountain. It has a lot of flags origin, same site, domain, secure flag, HTTP only, expiration etc.
In a nutshell token !== userInfo. You can't treat both in a similar way.
In React use Redux with its Redux Persist. By using these libraries the token is not disappear on page refresh. And also you don't need to pass AUTH token to child components as by storing Token as a state in redux it accessible in all components.
As for me the best way is to create double tokens authorization (access and refresh tokens), store tokens in LocalStorage and then refresh tokens by delay or requests.
Just ask your backend developer to add one route for tokens refresh.
For refreshing you can use axios interceptors.
Refresh token functionality in React application using redux and redux-saga
I am building a web platform to connect learners with tutors using Firebase Auth and Firestore. I am storing the learners' user info in a Firestore collection, and the tutor's info in another. I am building a function that can detect if a client is a learner or a tutor upon login.
One solution I was thinking is to query in which collection the user is found using UID. Although, this is a potential solution. But it sounds like it requires a lot of transaction, and may have a long run time if collections get big. Is there something else I can do for that? I am wondering if I can use authentication to build an embedded identity to each user to differentiate between "Tutor" and "Learner"? So each time the user logs in, we know the identity immediately?
I know that in the decoded authentication token, there is info such as this:
{ iss: 'https://securetoken.google.com/xxxx',
aud: 'xxxx',
auth_time: 1569886929,
user_id: 'aB03',
sub: 'aB03',
iat: 1570582588,
exp: 1570586188,
email: 'aa#gmail.com',
email_verified: false,
firebase:
{ identities: { email: [Array] }, sign_in_provider: 'password' },
uid: 'aa3' }
Can I leverage one of these to build what I want?
Really appreciate your time and help.
Since you mention "collection", I assume you're looking to use Firestore. In that case: the size of the collection has no effect on the query performance. No matter if there are 1,000 user documents in the collection, 1,000,000 or even 1,000,000,000, the time it takes to query for a single user document will always be the same.
Aside from that you can also store the user's type in the ID token (which is what you've shown in your question). This is known as a "custom claim", since you're adding a custom property for your app to the information. You'll want to do this from a trusted environment (your development machine, a server you control, or Cloud Functions), as I'd assume users should not be able to change their own role. See the documentation on controlling access with custom claims for more information on this.
So I have a single page frontend only app. Right now I have something like this
// db.js
import firebase from "firebase/app"
import "firebase/firestore";
var firebaseConfig = {
...
};
export const db = firebase
.initializeApp(firebaseConfig)
.firestore();
in main.js I was experimenting with putting the db instance in the global window scope just to see if I could go to the chrome web console and access it to submit a doc and indeed I can
// main.js
import { db } from './db'
window.db = db;
and then from chrome console
db.collection("test").add({'somekey': 'Can I add this doc?'})
How do I prevent someone from doing this without having a real backend to check auth? I like the reactivity of vue + firebase. If I don't expose the db variable to global scope is that enough? I was reading this post:
https://forum.vuejs.org/t/how-to-access-vue-from-chrome-console/3606/2
because any variable you create inside your main.js fiel will still not be globally available due to how webpack
One of the great things about Firestore is that you can access it directly from within your web page. That means that within that web page, you must have all configuration data to find the relevant Google servers, and find your Firebase project on those servers. In your example, that data is part of firebaseConfig.
Since you app needs this configuration, any malicious user can also get this data from your app. There is no way to hide this: if you app needs, a sufficiently motivated malicious user will be able to find it. And once someone has the configuration, they can use it to access your database.
The way to control access to the database, is by using Firebase's server-side security rules. Since these are enforced on the server, there is no way to bypass them, neither by your code, nor by the code that a malicious user writes.
You can use these security rules to ensure that all data is valid, for example making sure that all the required fields are there, and that there's no data that your app doesn't use.
But the common approach is to also ensure that all data access is authorized. This requires that your users are authenticated with Firebase Authentication. You can either require your users to sign in with their credentials, or you can anonymously sign them in. In the latter case they don't need to enter any credentials, but you can still ensure for example that each user can only write data to their own area of the data, and that they can only read their own data.
I have a Torii adapter that is posting my e.g. Facebook and Twitter authorization tokens back to my API to establish sessions. In the open() method of my adapter, I'd like to know the name of the provider to write some logic around how to handle the different types of providers. For example:
// app/torii-adapters/application.js
export default Ember.Object.extend({
open(authorization) {
if (this.provider.name === 'facebook-connect') {
var provider = 'facebook';
// Facebook specific logic
var data = { ... };
}
else if (this.provider.name === 'twitter-oauth2') {
var provider = 'twitter';
// Twitter specific logic
var data = { ... };
}
else {
throw new Error(`Unable to handle unknown provider: ${this.provider.name}`);
}
return POST(`/api/auth/${provider}`, data);
}
}
But, of course, this.provider.name is not correct. Is there a way to get the name of the provider used from inside an adapter method? Thanks in advance.
UPDATE: I think there are a couple ways to do it. The first way would be to set the provider name in localStorage (or sessionStorage) before calling open(), and then use that value in the above logic. For example:
localStorage.setItem('providerName', 'facebook-connect');
this.get('session').open('facebook-connect');
// later ...
const providerName = localStorage.getItem('providerName');
if (providerName === 'facebook-connect') {
// ...
}
Another way is to create separate adapters for the different providers. There is code in Torii to look for e.g. app-name/torii-adapters/facebook-connect.js before falling back on app-name/torii-adapters/application.js. I'll put my provider-specific logic in separate files and that will do the trick. However, I have common logic for storing, fetching, and closing the session, so I'm not sure where to put that now.
UPDATE 2: Torii has trouble finding the different adapters under torii-adapters (e.g. facebook-connect.js, twitter-oauth2.js). I was attempting to create a parent class for all my adapters that would contain the common functionality. Back to the drawing board...
UPDATE 3: As #Brou points out, and as I learned talking to the Torii team, fetching and closing the session can be done—regardless of the provider—in a common application adapter (app-name/torii-adapters/application.js) file. If you need provider-specific session-opening logic, you can have multiple additional adapters (e.g. app-name/torii-adapters/facebook-oauth2.js) that may subclass the application adapter (or not).
Regarding the session lifecycle in Torii: https://github.com/Vestorly/torii/issues/219
Regarding the multiple adapters pattern: https://github.com/Vestorly/torii/issues/221
Regarding the new authenticatedRoute() DSL and auto-sesssion-fetching in Torii 0.6.0: https://github.com/Vestorly/torii/issues/222
UPDATE 4: I've written up my findings and solution on my personal web site. It encapsulates some of the ideas from my original post, from #brou, and other sources. Please let me know in the comments if you have any questions. Thank you.
I'm not an expert, but I've studied simple-auth and torii twice in the last weeks. First, I realized that I needed to level up on too many things at the same time, and ended up delaying my login feature. Today, I'm back on this work for a week.
My question is: What is your specific logic about?
I am also implementing provider-agnostic processing AND later common processing.
This is the process I start implementing:
User authentication.
Basically, calling torii default providers to get that OAuth2 token.
User info retrieval.
Getting canonical information from FB/GG/LI APIs, in order to create as few sessions as possible for a single user across different providers. This is thus API-agnotic.
➜ I'd then do: custom sub-providers calling this._super(), then doing this retrieval.
User session fetching or session updates via my API.
Using the previous canonical user info. This should then be the same for any provider.
➜ I'd then do: a single (application.js) torii adapter.
User session persistence against page refresh.
Theoretically, using simple-auth's session implementation is enough.
Maybe the only difference between our works is that I don't need any authorizer for the moment as my back-end is not yet secured (I still run local).
We can keep in touch about our respective progress: this is my week task, so don't hesitate!
I'm working with ember 1.13.
Hope it helped,
Enjoy coding! 8-)