I am thinking of using a JWT to secure my .net Core WebAPI endpoints for a public API. This API will only be consumed by a React front end that does not require a user to authenticate. I am trying to ensure that only my React app can call my WebAPI endpoints.
My thought is to include the JWT when the React app is downloaded/initialized and use it when calling the API.
Thoughts on this? Are there other more efficient ways to do this?
My thought is to include the JWT when the React app is downloaded/initialized and use it when calling the API.
I guess that way wouldn't work because I can copy the JWT token/API-Key or whatelse from network easily and use it for sending own requests. If your API is setup well (validation etc.), sending requests "manually" shouldn't be a problem. So why you only want your react app to request your app?
The only way (I guess) to give only your react app access to the API is to configure your API-server/proxy to accept only requests from the same domain.
Related
I understand that React app is only client side application running in the client browser.
However I have the backend with REST API I need to consume, and the API in under mutual TLS (https), so I need client certificate in order to be able to authenticate and get something from the backend.
But the issue is that the React Front End is running locally in the browser so I do not know how it could be possible to securely store certificate and its private key, if it is even possible.
I was trying to google approach and it seems that the React app cannot consume services which require client certificate for authentication, and there should be at least another backend as proxy, which will be handling both parts, with the React client, and the REST API backend. This proxy can be configured with the certificate and private key and user would not have access to it.
But it requires another component as proxy.
I can also put the React app behind proxy like Apache and setup the mutual client certificate based authentication, however this can help me to identify user inside the React app, not to securely establish mutually authenticated channel with the REST API backend.
It seems that WebAuthN could be the way, however it seems to be designed only for authentication, not the SSL/TLS.
What should be the correct approach? Is it possible to do it with React based app, or this technology is not suitable in that case?
I did research on the same topic, the only solution that I found is to store the certificate on the api and request the certificate using AXIOS.
On the api level you need to test from where the request is coming from and only serve the certificate if the request comes from an authorized IP (your front end).
I couldn't find any other solution.
I am building a project with both a web app built with React and Next.js and a native app built with React Native. I am looking for a second opinion on the best practice to handle Authorization for the Spotify API that will work on both platforms.
Option 1: Use the Authorization Code Flow with a proxy server to protect the client secret.
Native app passes authorization code to proxy server on heroku using GET request
Proxy server passes code, redirect_uri, grant_type, client_id, and client_secret to Spotify API
Proxy server passes back access_token, refresh_token, and expires_in to either web app or native app
Option 2: Use the Implicit Grant flow and accept that there is no
refresh_token. I would like to avoid this option if possible because the app will be making many requests and it would be more convenient to operate with a refresh_token.
My main concern is keeping the client_secret safe since my understanding is that React and React Native do not make requests server-side. Is it safe to pass back the access_token and refresh_token for a proxy?
I have some trouble understanding the MSAL authentication and authorization. I have a single page app developed in React. I have setup the MSAL Azure SSO authentication by registering the web app on the Azure AD. Now, I have a Web API (in .Net Core) which is running on a separate app service. How do I integrate the authentication from my React app to the Web API?
Few questions coming to mind:
Do I have to register the Web API app as well similar to my React app?
Do I have to pass the auth token from my React App to the Web API?
Do I have to setup the authentication only on the Web API side (using MSAL.Net) and the React App will connect to it?
Please share your thoughts. Let me know if I can explain any better.
If you are the author of both react app and web API, you can register just one app and use ClientId for both.
Yes. If your react app is standalone app (not a part of Asp.net app) you can use msal.js to login with AzureAD and then use openId token to login to your web API. Also you can use access token to access services secured by Azure (e.g. Microsoft Graph) directly from React.
If your React app is a part of Asp.net app, you can setup Auth on server. If it's standalone app you need to use approach from 2.
If your React app is standalone app and if you are going to access "downstream" API (like Microsoft Graph) from Web API, you need to implement On-Behalf-Of mechanism on your Web API. In two words:
- user login with React app and access Web API with openId token;
- Web API acquires new access token based on token sent from client
- Web API access Microsoft Graph with this new access token.
You can find Server side example here.
Client side example from another answer works in this case, but you need to send row openId to Web API instead on access token.
P.S. You can use access token instead of idToken to access your WebAPI as well, but in this case you need to define separate scope for your WebAPI in Azure as well. After that you can use this scope to access your WebAPI and separate set of scopes to access MS Graph.
Here is a complete video tutorial and source code on how to use MSAL with React to call Microsoft Graph.
The only different in your case will be that instead of calling Microsoft Graph, you will call your own API.
Bottomline is - there is no direct integration package yet for react. Which can also be read from the official statement on the msal-js repo:
After our current libraries are up to standards, we will begin
balancing new feature requests, with new platforms such as react and
node.js.
See Here. It allows you to call Graph API from client side.
I've a SPA (Angular based) published at my-example-domain.com and rest API (based on Laravel 5.3), exposed at my-example-domain.com/api.
All API are public, so unauthenticated user can use my Angular SPA and call backend API.
I would like to allow ONLY my SPA to call my backend rest API so, for example, nobody should be able to call my rest APIs through a rest client/curl.
How can I reach this goal?
What kind of authentication should I have to set up in my Laravel app?
Is Passport the right way?
You can't.
Your client is available to the public.
It runs in a browser, so all the HTTP requests it makes can be inspected by its users (i.e. everyone).
Anything you do to try to identify the request as coming from your client, can be inspected and replicated by anyone.
I am building a simple AngularJs web app that hits a REST Api built with Flask. From what I understand, there are a few ways to protect against CSRF, one of which is sending back a CSRF token when the user authenticates.
If I wanted to make my API available to both the Web Application and to users who want to use it as an API for development, would I need 2 endpoints for each endpoint that allows POST requests [one for the app that requires CSRF token + auth token and one for the developers that requires just an api access key]?
Not necessarily. Broadly, you have two options:
Proxy the REST API through whatever server-side container your web app is running in. Your web-app proxy can then implement the CSRF protection and insert the API-key into the API request.
Check the referrer header on all API requests. Although this requires that your Angular SPA and API share the same authentication mechanism, so you'd have to use something more sophisticated than an API key, like OAuth.