I’m in the process of creating a React application that will use Spotify’s web api to compile different types of analytics from each users’ Spotify account.
I set up my react app to use Firebase’s authentication so users can create an account and once logged in, link their spotify to that account.
The goal is to store important info in the user database like the web api’s refresh token so they don’t have to re-link their account in the future when they log in. However, I have very little experience with any of these frameworks and don’t know the best way to handle authenticating each users’ spotify account within my React app.
Should I also create an express server to handle the callbacks for my spotify authentication, database queries, and sending data to the front end, or can all of this be handled in React? And if it can be handled in react, where should I set the callback uri to go? The app has a home page for new users to see its features, and a dashboard page that they go to once logged in.
Sorry if this isn’t very well described, but Im basically just looking for the best practice stack to use for a React-Firebase App that uses the spotify web api, and whether or not I need to separate the spotify authentication into some backend to handle those requests.
I tried setting the callback to go to the Dashboard, but that means every time the user goes to the dashboard it has to check for the callback url parameters that it sends, which doesn’t seem like the best way to handle it.
I also tried creating a /callback page to handle the spotify authentication, which worked but meant there was a random callback page on my site, which also doesn’t seem ideal, so Im not sure what the best way to handle it is.
Related
I'm building a React frontend which calls several Azure Functions API's. Users don't have to login. Now I have a host key, which I include in the requests to the functions, but sending this api key to the client-side doesn't feel very secure. Now I know that I can use process.env, but that still isn't very secure I think.
Is there a way to do this securely?
Thanks!
Simple rule: Nothing can be kept secret in an Angular/React SPA that is executed on the client side.
You could go down the path of server-side rendering of your React app, call the Azure Function API on a server and only return already rendered pages to the user. That way your users don't see keys but of course they still cause API calls with every page load.
I've started building a prototype for a front-end layer with single-spa. The layout is very similar to https://github.com/react-microfrontends, which means:
Root config
A navbar (React)
Two apps (Both React)
A Styleguide module
An API module to handle communication with a set of API
I managed to get a basic prototype running, but I now need to implement some OAuth2/OpenID based authentication, and I'm not sure where to start. I need the user redirected to a separate URL (Auth0 style) if not authenticated or not having a valid JWT, then I need a mechanism of token refresh whenever the auth token expires. On top of any general advice on best practices, existing examples and so on, I have some specific questions I can't quite work out.
How can I redirect the user to a different URL when not authenticated? Which of the modules/components should be responsible for it?
Is there a library that implements OAuth2 out of the box? In particular, I'm interested in some sort of automatic token refresh.
What is the best way to make sure an unauthenticated/unauthorized user cannot access the app bundles?
Thanks in advance.
The typical approach would be to set up an Auth microfrontend that would :
handle credenials retrieval upon login. Be it via Password flow or OAuth ( in your case). Since you are using React, your OAuth provider should have a library that you can use within the Auth MFE to interact with it. If it's keycloak, React Keycloak is a good fit. There's no rule lf thumb here.
pass the credentials to your two React Apps ( Microfrontends) and the API module via Browser storage or shared state.
Doing so, the API module would set the credentials in the API calls. and the two react Apps would check credentials presence before proceeding with their inner logic.
refresh credentials on expiration or log out user ( depending on your logic ). Loging the user would mean deleting the credentials from browser storage for example.
redirect to one of your react App after login. That means the Auth MFE route should always be active in the root config.
I hope it helps. Here I have summarised the flow.
More of it on my github account https://github.com/exaucae/single-spa-patterns/blob/master/AUTHENTICATION.md
I have just started learning authorization and authentication in react, and I'm writing this after finishing my first simple login system using JWT, as most of you know you store a token in the browser and then you compare it with the saved tokens in your backend now when that validation is done truly I set Authenticated Boolean to true and gain access to the website, after finishing that simple system I checked react dev tools and I found out that I can just change the boolean to true and bypass all of the authentication work!
And I have searched online for resources and tutorials to fix that massive problem but didn't find what was I looking for all I found is how to setup Authentication or protect a router similar to the way I did, but not deeply secured.
So can anyone recommend a course or tutorial paid or free to learn more about security and authentication?
Since React apps are single page apps (if you are doing client-side rendering), the entire application (all html/css/js files) is sent to the client in the initial request. Generally authentication works in the way you have stated where the authentication status of the user is stored in the application state. This, of course, means that someone familiar with web applications would be able to set the variable isAuthenticated to true. If you have sensitive information kept statically (written literally in html/css/js) then this would be an issue.
The reason this scenario is not generally seen as an issue is because React apps usually do not hold any data. And data is usually the sensitive stuff in an app. Data can be tied to the user and should not be exposed to those who are not properly authenticated or do not have the required permissions. Data is held by the server, which can control what it sends out (checking for verified JWTs) via the API to the app. So your server should check for a valid JWT on any request that returns sensitive information—generally all requests except those for the app itself and authentication requests.
In short: Yes, someone can get access to the "authenticated" side of your app, but any requests to the API for data by the app at this point would (or should) be blocked as unauthorized (i.e. status 401). So they can see what the app looks like to an authenticated user, but would not be able to see any sensitive information.
(Note: if you do store sensitive information statically (as mentioned above), consider storing it on the server and having the app request that info via the API and requiring a valid authentication token).
If you would like to block the possibility of an unauthenticated user gaining access to the authenticated side of your app, you could make the login page its own app or HTML doc and only send the full/authenticated version of the app to authenticated users.
PS
Just note I am pretty new with react(with redux) and express in general.
My question is more of a "what do I do now?" or "help me in the right direction,please" type of question.
My english is very bad.
I am not afraid to teach myself , just show me where to look.
Most internet resources are half explained or assumes you are a pro.
I have a react client side application that needs user authentication, and after the authentication the react application needs to know if client is logged in or out
Now currently my react application is using conditional rendering which means my entire application is depended on the app-level state.
When my react application starts it starts with a login component where the user can add his email and password
Now from here on out I am completely stuck on what to do,so many questions...
How do I authenticate(from the backend) the user using his login input(email/password) and check agiants users in mongoDB if he is there or not, and if he is there how do I let front-end application know he is valid user and use that user information to access certain routes?
How can I check if user is logged in(after authentication and valid user have been authenticated) from front-end react application
Can I use cookies as a possible solution?For example set a cookie on the server-side(express) and access the cookie on the client-side(react) and vice-versa?
Little of topic(or maybe on topic) question? What is Passport.js and it help with my current dilemma ???
as far as authentication is concerned, using a JWT which will be saved in session storage and can be sent to your server app via API is a very popular approach with react/redux applications. this will be sent with all api requests so that the server app can verify that the user is logged in before serving data to them. to check if someone is logged in on the client app, you should have a reducer/saga/thunk that, upon recieving a successful login message from the server app, will update the auth reducer portion of the redux store to flip a boolean isLoggedIn property that you can expose to your props to check if you are logged in.
have a react client side application that needs user authentication, and after the authentication the react application needs to know if client is logged in or out
Now currently my react application is using conditional rendering which means my entire application is depended on the app-level state.
When my react application starts it starts with a login component where the user can add his email and password
there is a react-redux structure called the duck structure that is very good: https://github.com/erikras/ducks-modular-redux
sorry but I do not have mongodb experience but search for authentication handling and there will definitely be examples. .NET Core is excellent and there are many tutorials if you consider changing.
So I built an App using Firebase as backend. Now I need to use Stripe to charge use and send payment (or PayPal, whichever works). And I google around solutions. Most of them do require a backend with Node.js. But that defeat the purpose of using Firebase at the first place. I use Firebase b/c I do not want to build an backend with Node.js.
Then I heard stamplay. I do the same thing as Firebase but also provide out of the box integration with Stripe (and Mailchimp!).
I do not want to change my app and keep using Firebase Authorization, managing users and store most of the data in Firebase. But come to dealing with payment, I want to use stamplay to connect with Stripe. But I do not where to start. So far, seem like the only way to use stamplay stripe (with AngularJS) is to use stamplay user Authorization, create user in stamplay and then use Stripe task - ditching Firebase completely. Can someone point me in the right direction use both these amazing services together - stamplay for APIs and Firebase for everything else?
Here is Giuliano (stamplay co-founder) nice to emeet you. I understand that you want to leverage our Stripe integration while still keep using Firebase for auth and data storage. To be able to seamlessly charge end-users of your app we automatically tie each one of them to a stripe customer.
If you want to stick to Firebase auth you need to mirror, at least partially, your users. Everytime you have a new user signed up you can forward it to stamplay and use a task to create a stripe customer binded to it. Then you can move on to leverage our integration by collecting user's credit card information.
The overhead of this approach is that you need to care about a kind-of Single sign on across both Firebase and Stamplay auth. What is currently Firebase auth providing that we cannot cover?