I would like to add an Azure AD configuration to my React&Node.js project. What I want is to log in on Frontend using Azure AD and then send a request with f.e axios to my backend written in Node.js, so that Node.js knows that the user is logged in and can perform the request. I was reading tutorials/documentation on Microsoft site for all day, but I still don't know how and where to start. Basically, almost every Microsoft Tutorial is either to call a Microsoft Graph API from Node.js or from React.js. I completely do not want to use Microsoft Graph. I just want to have simple login on frontend and protected endpoints from un-logged user on backend. The other tutorials that I find are too complicated f.e https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/3-Authorization-II/1-call-api . I understand the concept of App registration, client id, tenant id and etc. but I simply don't know how to write a code that: login, send the request with token - then is accepted/declined by Node.js .
If by any chance, somehow did an application like that, or can provide me a link to a well written tutorial, so I would understand and recreate it in my scenario, I would be grateful.
Related
There is plenty of tutorials and articles on this precise question but each one contradict the previous one,
I'm trying to make a signup and login reactJs pages with Firebase js sdk on the frontend, that's what I found most of youtubers devs do,
And then I found that is not secure (doing the authentication on client side).
You should use the Firebase Admin SDK (firebase.google.com/docs/admin/setup) on Firebase Cloud Functions or a self-hosted server in that case. Everything else would just be a dirty hack – PRSHL source
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves. source
I really want to understand if it is not secure to use it on the client side, Why does firebase provided it in the first place ?? or is there another way to properly write the auth using firebase js sdk on the frontend ? of course without using admin sdk
Or should I use firebase js sdk on the backend with express ?
I only want clear and detailed answers please !!
My best guess is that you're confused between authenticating a user client-side and the fact that Firebase provides a client-side SDK for authenticating users.
Though all you have to do to use Firebase Authentication in your app is implement its client-side SDK, there are many more parts involved in the process - and quite a few of them run on secured servers.
It's just that Firebase (and the authentication providers it supports) have implemented the server-side of the authentication process for you already and made the variables parts of the process part of the configuration that you provide either in the Firebase console, the provider's web interface, and/or in the configuration that you specify when you initialize the Firebase SDK in your client-side application code.
From the comments you now added, the second is correct and explains exactly what the risk is:
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves.
So while you can safely create a user account on the client (a process known as authentication), marking them as an admin (a process known as authorization) has to happen in a trusted environment as otherwise any user could make themselves an admin.
I want to make Shopify non - embedded apps, I have installed the pre-built code which Shopify provides to build an embedded app. In the server.js file, after the user installs our app, it gets the access Token successfully. In order to make an API request to graphql server, it requires the access token to the headers. I am struggling with this point, I don't know how to get that access token from the backend and make API calls on the frontend, I want to use Apollo Client to show query data on the frontend, but I don't know how to use that accessToken after the merchants install the app, it has generated it in the server.js file, which is the backend. Are there any tutorials or docs on what I am trying to achieve.
It seems like this is going to apply for any type of front-end that you're using and isn't specific to Apollo, have you tried checking the related doc? If so, add the relevant code to your question 🤠
I've currently got a REST API (written in Java using Spring) and a frontend for that API (written in Javascript using Express) which will query that API for the data to display. I've not gotten too far along in the frontend, and wanted to add in my Authorization/Authentication. I would like to use Azure Active Directory (AAD) for this - we have users in AAD, so this is what we're pursuing. I understand that I can use the MSAL.js library to get an access_token that I can then send to my Java REST API for validation. However, I'm not able to find any decent documentation or examples for this specific case, though. I see a some Javascript Single Page Application (SPA) documentation and examples, but seeing as this is AuthN/AuthZ, I don't want to have a kinda correct solution, because this is important stuff. I also want to make sure I'm handling caching, sign outs, etc, in the right manner.
If anyone could point me in the direction of some documentation, examples, readings, etc, I'd be very appreciative!
Thanks!
You can use MSAL.js to easily integrate with the front end of your API for authentication/authorization of your users.
For java web apps, you can use the MSAL4J authentication library, so that the application can be integrated with the Microsoft identity platform. It allows you to log in to a user or application using a Microsoft identity (Azure AD, Microsoft account, and Azure AD B2C account) and obtain a token to call the Microsoft API.
For more details, please check:here.
I am using Meteor 1.10 + mongodb.
I have multiple mobile chat & information applications.
These mobile application are natively developed using Meteor DDP libraries.
But I have same users base for all the apps.
Now I want to create a separate meteor instance on separate individual server to keep the users base centralized.
I need suggestions that how can I acheive this architecture with meteor.
Keeping reactivity and performance in mind.
For a centralized user-base with full reactive functionality you need an Authorization Server which will be used by your apps (= Resource Servers) in order to allow an authenticated/authorized request. This is basically the OAuth2 3-tier workflow.
See:
https://www.rfc-editor.org/rfc/rfc6749
https://www.oauth.com/
Login Service
You will also have to write your own login handler (Meteor.loginWithMyCustomAuthServer) in order to avoid DDP.connect because you would then have to manage two userbases (one for the app itself and one for the Authorization Server) and this will get really messy.
This login handler is then retrieving the user account data after the Oauth2 authorization request has been successful, which will make the Authorization Server's userbase the single point of truth for any of your app that is registered (read on Oauth2 workflow about clientId and secret).
Subcribing to users
The Auth server is the single point of truth where you create, updat or delete your users there and on a successfull login your local app will always get the latest user data synced from this accounts Auth Server (this is how Meteor does it with loginWith<Service> too)
You then subscribe to your users to the app itself without any ddp remote connection. This of course works only if the user data you want to get is actually for online users.
If you want to subscribe for any user (where the data might have not been synced yet) you still need a remote subscription to a publication on the Authorizazion server.
Note, that in order to authenticate users with this remote subscription you need an authenticated DDP request (which is also backed by the packages below).
Implementation
Warning - the following is an implementation by myself. This is due to I have faced the same issue and found no other implementation before mine.
There is a full working Accounts server (but constantly work in progress)
https://github.com/leaonline/leaonline-accounts
it uses an Oauth2 nodejs implementation, which has been wrapped inside a Meteor package:
https://github.com/leaonline/oauth2-server
and the respective login handler has also been created:
https://github.com/leaonline/meteor-accounts-lea
So finally I got a work around. It might not be the perfect way to handle this, but to my knowledge it worked for me so well. But yes I still open for suggestions.
Currently I have 4 connecting applications which are dependent on same users base.
So I decided to build SSO (Centralized Server for managing Users Database)
All 4 connecting applications ping SSO for User-Authentication and getting users related data.
Now those 4 connecting applications are developed using Meteor.
Main challenge here was to make things Reactive/Realtime.
E.g Chat/Messaging, Group Creations, Showing users list & listeners for newly registered users.
So in this scenario users database was on other remote server (SSO), so on connecting application I couldn't just:
Meteor.publish("getUsers")
So on connecting applications I decided to create a Temporary Collection called:
UserReactiveCollection
With following structure:
UserReactiveCollection.{
_id: 1,
userId: '2',
createdAt: new Date()
}
And I published subscription:
Meteor.publish("subscribeNewUserSso", function () {
return UserReactiveCollection.find({});
});
So for updating UserReactiveCollection I exposed Rest Api's on each connecting application respectively.
Those apis receive data from SSO and updates in UserReactiveCollection.
So on SSO side when ever a new user is registered. I ping those Apis (on connecting applications) and send the inserted userId in the payload.
So now those connecting applications receives onDataChanged ping from the subscription and gets userId.
Using that userId the connecting applications pings back to SSO and get user details of that specific userId and prepends to the users list.
Thats how I got it all working so for now I am just marking my answer accepted but as I mentioned above that: "It might not be the perfect way to handle this, but to my knowledge it worked for me so well. But yes I still open for suggestions."
And special thanks to #Jankapunkt for helping me out.
I'm looking for advice on how to properly put an environment like this together. There's a ton of info out there and a ton of material to cover in the Quickstarts, but I'm still feeling fairly lost after 3 days of trial-and-error. I'm familiar w/ Identity Framework in the .NET Framework, but have never worked with Identity Server prior to this.
We've got a microservices setup built on Node and MySql...a series of services in Docker containers which talk to their own db nodes in a MySql cluster. We have a single management UI built in React & Redux - it will run from an AWS bucket.
I've been tasked with authenticating this React front-end using Identity Server. We will NOT be doing auth on the APIs with it. I've suggested building the authentication UI in .NET Core using Identity Framework, since it gives us everything we need "out of the box".
Eventually, The two Identity apps will be our SSO for all applications written against these APIs, and even those that aren't. Furthermore, I'll need to incorporate AD at some point to allow internal company users to pass through w/o manually authenticating.
What (I think) we need is the following:
Identity Server 4 running in its own container
Core Identity MVC app running in own container
Use oidc-client on front-end to authenticate
What I've done so far, is follow these two tutorials:
http://docs.identityserver.io/en/release/quickstarts/6_aspnet_identity.html#new-project-for-asp-net-identity
http://docs.identityserver.io/en/dev/quickstarts/7_javascript_client.html
My result is a running Identity Server and Identity Core MVC app running together in the same project (two different ports.) After following the JS client tutorial, I have their example code running - it redirects me to the MVC login, which authenticates against Identity Server, then returns this result:
{
"sid": "8e60eb65960d967834cb3eb4fdcbbd49",
"sub": "dfc90bd1-cad4-45d0-84bd-174e8a6ca891",
"auth_time": 1516296631,
"idp": "local",
"amr": [
"pwd"
],
"preferred_username": "me#gmail.com",
"name": "me#gmail.com"
}
Clicking logout fails, but that's because the controller example in the first tutorial doesn't include a GET for a logout, like the example controller buried in the JavaScriptClient example.
It feels like I'm getting somewhere but at the same time, I now fully realize how little I know. Could use advice, or even just a pointer to the correct Quickstarts to achieve what I'm looking for.
Base Setup
Based on what i read ideally what you want to do is break it up into 3 components
Identity Management component
API Component
MVC/MVVM component
For the Identity Management component use this quickstart as example ASPNetIdentity + IS4 EF or this one without the EF component.
Your API should be only authorizing (not authenticating) with all the authentication and registration occurring on ID4 server.
Your frontend (MVVM or MVC client) should be registered with ID4 server with all the bells and whistles as per tutorials:
MVC
Javascript
This should enable you to have a API(s) that is/are secured, single IdentityManagement source (basically build onto it to be a true SSO/Federated Gateway), all while separating the front end of your application(s).
Hope this helps.
Additional Info:
Further to the answer there are libraries you can use (or build yourself) for OIDC client for react that you can put into your front-end to help you achieve some results quicker.
FYI I use angular + id4 with AspCoreIdentity + AspCore API.
All that i need to do is create the link between javascript client and ID4 (as per tutorial and ID4 and Web API. We used the industry library for oidc-connect in angular to put in the settings for the ID4 server and Web API.
The beauty of this is once you do the basic setup on ID4 there is not much required to build on it for more advanced features.
Just keep in mind that these are separate components and treat them exactly as that. Helped me with the confusion and lack of knowledge.
Windows and AD login (future state):
Keeping these components separate, will enable you to integrate AD into the ID4 Server much easier and quicker without having to make modifications to API or Frontend app. Example leveraging Windows login here.