I'm trying to implement SSO on my React-Redux app using an OpenID-Connect provider. The intent is to protect all components and redirect the user to the Identity Provider's login page if the session ends.
This is why I cannot have a dedicated Login page (component) in the application.
I've read that saving JWTs in the localStorage could be a good idea so I was thinking of using a flag isAuthenticated in the Redux store and keep JWTs in the localStorage. I can then fetch the JWTs from the localStorage to authenticate other APIs I'd be calling from within my app. Is this approach appropriate?
Moreover can anyone point me to a library/package that I can use to fetch (and refresh) JWTs for this purpose? I went through a lot of documentation and tried out the following but couldn't get these to work:
redux-oidc: I don't have any specific Callback component in my application so I don't quite know how to apply this approach to my app.
passport-openid-connect: Passport relies on storing sessions in cookies but I'd like to use the localSorage instead.
redux-auth-wrapper: A higher order component sounds great but I still cannot figure out how to integrate it without any dedicated Login component.
Could someone please guide me through? I'm a newbie to the React ecosystem so please excuse my incomprehension.
Any help would be much appreciated!
Thanks
You are on the right track - redux-oidc manages your Redux state with the login details - the client library that actually manages the JWT (implicit flow), redirecting to the IdentityServer (whichever) login page and returning to your app (the "callback") is oidc-client.
redux-auth-wrapper is just a HOC (High Order Component) - basically a wrapper to check if the user is authenticated (either in the Redux store or with a custom function) and forward to a login page - in my opinion you do not really need it as redux-oidc already gives you everything you need.
I personally also implemented an IdentityServer4 - to centrally manage all external providers - and it's been working great so far.
I would suggest first looking at https://blogs.msdn.microsoft.com/webdev/2017/04/26/the-mvp-show-learns-about-asp-net-identity-server-and-heidelberg/ where the creator of IdentityServer4 is explaining extremely well how the identification works and the flows (implicit vs hybrid).
Once you know the Identity basics and how it all hangs together, have a look at the redux-oidc sample (very easy to follow).
Have fun ;)
Related
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.
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
We have asp.net core(v3.0) Web API backend(no auth yet). A frontend is going to be a SPA(React).
A frontend basically will be an admin panel, it means the website's home page should be just the login page. We are planning on using IdentityServer4 for auth(separate project). If we create the IdentityServer4 project(MVC) it will have its own login form/page. Since opening our client website(react) login form should be opened, popout and iframe is not the way we are considering to use, what is the best way to accomplish this?
I've done some research and it seems it is possible to make our login form in react client and send the users login and password to IdentityServer4 if the client is set as ResourceOwnerPassword flow. But, it is not a secure and recommended way. I've read a lot of questions in SO and a lot of articles, but that is outdated and most of the samples are in IdentityServer4's repo is deprecated.
Questions:
Another way we are thinking is, on home page load, just redirect to the IdentityServer4 login page(MVC) and after login redirects back to our website. Is this a proper way of doing it? will the user see the redirection or it will not be much difference since the user opens our website and it seems like the home page?
What type of GrantType should I use for this case? Hybrid?
Is it possible to make a custom login page like in React?
What is the best way of implementing it?
Thanks for any advice, and my bad if the question is duplicated since I spend a couple of days to figure this out but couldn't.
Edit:
Now, IdentityServer4 with JavaScript client is available in IdneityServer4 official repositoty:https://github.com/IdentityServer/IdentityServer4/tree/master/samples/Quickstarts/4_JavaScriptClient
Also, I cloned and changed a little bit, so IdentityServer4 and WebApi are in a single project: https://github.com/Jamaxack/IdentityServerSPA
Is this a proper way of doing it? will the user see the redirection or it will not be much difference since the user opens our website and it seems like the home page?
That is recommended by redirecting user to identity provider's login page for sign-in , Resource Onwer Flow is not recommended as you said for security reasons.
What type of GrantType should I use for this case? Hybrid?
You can use Proof Key for Code Exchange (PKCE) which is already the official recommendation for native applications and SPAs . See Grant Types for more details .
Is it possible to make a custom login page like in React?
You can fully custmize the identity server's login user interface and identity management system , custmize the IdentityServer4.Quickstart.UI/ASP.NET Identity/Your own identity provider services .
In addition , ASP.NET Core 3.0 or later offers authentication in Single Page Apps (SPAs) using the support for API authorization. ASP.NET Core Identity for authenticating and storing users is combined with IdentityServer for implementing Open ID Connect :
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization?view=aspnetcore-3.1
1) You can use a flow something like below
'First, load the react project. then check for the token/user object. If there is no token/user, then redirect to the MVC project from react project. You can have the login page in MVC'
2) Use Implicit grant type
3) Yes. You can make customization in MVC login page
4) In order to do that, you can use the oidc-client npm package in react project. For the identity, use the Quickstart template from identity server 4 documentation.
Here it is
I am new to React.js and have a need to maintain session of the application...lets say for 3 minutes.
Authentication is done by a third party (akamai) and i need to have the session management. Can someone guide me on this? Any github code/video? TIA
Typically I would not recommend you manage sessions on the front-end as it's easy to hack.
With JWT (JSON Web Tokens) you create a token on your backend and your front-end just requests the latest token. Inside that token will be info on whether that session is still active (you'd control what is returned).
Find a good JWT guide set it up, then from React you make a simple fetch command to get the JWT and then parse it and boot the user as necessary.
There was a similar question to yours asked earlier in the year, please see below:
What is the best way to manage a user's session in React?
I am currently developing a small application with a couple of endpoints in nodejs and an angularjs frontend.
At the moment I have an endpoint for users and another one for events. The thing is, I was thinking of making all the GET methods require auth, so that someone that isn't logged in can't access the system, for that I thought of using PassportJS.
Anyways, my question/s would be the following:
What auth strategy should I use? Basic, OAuth or another? Why would that be? I mean, I understand how their flow works, but I don't know why one or another would be appropiate for my app.
Should the endpoints require auth or should it check cookies/token or something else in the session? I'm completely new to this, so I don't even know if this question makes sense.
In any case, I would appreciate any overall insight in the topic since I don't have any experience in developing applications with auth and security.
Thanks!
You have to provide more details about your authentication needs in order for someone to give you a definitive answer to this broad question.
Based on your question, one can assume you don't have any requirements though, therefore I could suggest JWT (JSON Web Tokens - https://jwt.io/)
There are nodejs libraries that can help you create, decode, verify JWT tokens. (such as jsonwebtoken). You can find more details about it on github.
Once someone is logged in, you could pass this generated token back to the client which could store it in the browser's session.
The token can be used in subsequent requests by appending it in the request header.
On the server side, you can add a custom auth middleware to the routes that require authentication, which will verify the token's validity and call the next middleware for the current route.