I'm stack in my very first task of my very first job as Front-End developer, I know I am hindered, but I hope you will be able to help me.
My task is the same as in the title, to configure the frontend to use b2c for authentication, I don't have to impletement the authentication itself, just to configure the b2c, I will explain a little bit the project so that you can understand better:
They have a main App which is already working perfectly and it is stable, what they want to do is to build a platform aside, where the the customers can send their complains, on this platform every customer should login automatically with the credentials of the main App.
They provided me the entrypontins (for authorization, the token endpoint and the end session endpoint), the jwks uri and the cliendID, the App is build in Nuxtjs and they are using Azure AD B2C as directory service. The App is absolutely empty, it was just created and the configuration I have to do is the very first thing that should be implemented.
I have found a lot of theory informations on the web, but I cannot manage to find a guide that could help me to implement it practically, and the most of the practic tutorials/docs are about implementing the full process of authentication.
I am wondering if some of you knows a nice tutorial or guide or something that could help me to take a few steps forward.
I thank you all in advance !!
Related
There is a lot of examples how to implement OpenID Connect auth. in Node - code grant (+ client password).
There is a lot of examples how to implement OpenID in React (SPA) - code grant with PKCE
Even I know that PKCE it's rather secure, however I feel bad to relegate authentication solely on client side.
Every React SPA has backend (at least it should be hosted somewhere).
I want to have server side in Node (Express) to securely save client password and make all heavy lifting with Identity Server and
React for front-end.
As I already said there is a lot of examples of "Node (Express) with template engines" for authentication.
But I want to use React as "template engine".
So, I am looking for full and correct implementation of it. Meanwhile I cannot find it.
Can anybody help me with it - to find an example?
You need some actual protection in the SPA / browser though, and the 2 common options are:
Plug in OIDC Client Library to do the heavy lifting, so that you don't write much security code yourself. This library runs a number of strict security checks before accepting tokens.
Use a proxying solution that results in your SPA getting a cookie.
For an SPA this tends to be a more of a home grown solution rather than a standards based one
RESOURCES OF MINE FOR OPTION 1
SPA Security Code
Explanatory Notes
FOR OPTION 2
You could use the Open Id Client Node JS Library server side, and follow it's guidance.
I've found 2 solution on the Internet.
The First :
Implement social authentication with React + RESTful API
On the frontend, get the 3rd party app’s login popup to appear.
(Still on the frontend) Grab the authentication token the 3rd party app returns after >agreeing to login.
(Yep, still frontend) Send that token to the backend as part of the body of your >request. (I like to use Blobs, but that’s just me.)
On the backend, verify the token.
If the token is authentic, you will receive the user as part of the verification >response (at least that’s the case with Passport.js, which we’ll be using).
Save the user’s data to your database.
Return a JWT token to the frontend. What you do with that token is out of scope for >this tutorial, but it should probably be used to authenticate each of the logged in >user’s actions.
Very well explained, with github working example social-auth-example
It's only for social authentications, but I think no problem to make something more general or at least to add my OpenID Connect Auth. provider.
The second example:
React Authentication with Twitter, Google, Facebook and Github
This approach uses socket.io. Very interesting.
P.S.
So, I need to figure out what solution is more secure and if there any security breaches.
Not easy task to do. It's so pity, there is no standard flow for my problem. I can find 1000 reasons why it's better to make all heavy lifting on back-end and not to rely on OIDC Client Library. The first reason is my boss :)
I have a WordPress Website that currently uses its own authentication.
I am building a new web app on React which would be on its sub-domain.
I will be using AWS Cognito for authentication.
Now I want to enable a single sign-on between the Wordpress site and the React App via Cognito.
i.e user logs in to the Wordpress site and when he navigates to the react app, he does not have to login again.
Please suggest how to achieve this.
I am going through the exact same process right now. It's not simple, but from what I gather it is doable. There are some things you must reconcile first:
You will need to set up a cognito user pool to house all of your user configurations going forward. You should set it up with the attributes and roles you currently use in WP, and to allow SSO.
Your existing WP users will need to be imported into the Cognito User Pool. You will not be able to import their passwords unfortunately, so you will need to notify them to reset the passwords (I suggest sending them to the cognito hosted login page if you want to use a federated login with social providers such as facebook, google, apple, etc. - LinkedIn is a bit of a pain as it uses Auth0 but still doable).
For the login integration, you will need to choose whether to use AWS AMPLIFY or just the JavaScript SDK. Several coders tried to convince me to use Amplify, but I felt the sdk was much cleaner. Especially for the Node.js as there arfe several packages you can use as well as the amazon docs ... https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/setting-credentials-node.html
For the Wordpress, this is a bit more tedious. There is, AFAICT, one plugin made by miniOrange that allows you to directly integrate an app pool, but the free functionality is limited, the docs are outdated and obscure, and I generally don't have a good feeling about their longevity. Nonetheless, I am using it for now.
Now for the fun part. Unifying the login between sites requires the use of Cognito's JWT tokens (JSON web tokens) to pass between sites. There are a number of docs that AWS offers, but none were clear to me, so I have resolved to hire someone to set these up. Here is a primer on that: https://itnext.io/aws-cognito-example-using-react-ui-and-node-js-rest-apis-part-3-jwt-secured-rest-apis-e56d336ce306
I know this is not a complete answer, but hopefully it saves you some time.
I have an existing J2EE application which provides some specific features after logging in to the application.
I have to provide SSO to just ONE of the customer who logs into our application while the rest of the customers would still use the login page and login with their credentials.
I am planning to use OpenAM Fedlet act as SP deployed as a separate application in our container.
I need some help in understanding if i need a full blown OpenAM instance deployed within us. Please provide any insights if you may have on this .
You can use the fedlet as an SP for this user. The trick is identifying this particular user and initiating SSO for this person, and going to the login screen for everyone else.
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
I'm coding a Python - Google App Engine application. There are 2 important things this app must do:
Write in user's calendar.
Write in user's profile (working with users in a Google Apps domain)
First operation is easy. If I understood OAuth, this is the classical 3-legged scenario. The scenario for which OAuth was originally developed. The logged user provides credentials to the client (my app) to access the user's data (calendar) on his/her behalf. So, this can be done just with the logged user's credentials.
Second operation is not so easy. It can't be done with just the logged user's credentials. This is a 2-legged OAuth scenario. So, I need to delegate in a Google Apps domain admin's account to access the users's profiles using Google Profiles API (via google data library). So far, I hardcode admin user/password in a json file, and my app loads that file. But that sounds kind of dirty for me.
At the end, my app needs to handle the classical 3-legged OAuth scenario (no problem, just need the logged user's credentials) plus a 2-legged OAuth scenario (need administrator credentials).
Is there any official or more elegant way to handle both scenarios in Google App Engine, working with Google Apps domain, that hardcoding admin credentials?
Many thanks in advance
AFAIK there is no way to authorize a write operation to Google Contacts Data API using 2-legged OAuth.
Google's documentation specifies which APIs are accessible via 2-legged OAuth, but it seems that someone at Google's forgot to specify that some of them are read-only :-S
Some people had the same problem here and here.
I look forward someone at Google to fix this. Until then, harcoding admin-level credentials is the only option I know that it works. I don't like it at all: it's dirty but effective. If someone knows a more elegant zen-level way, please illuminate us!