I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
User populates React-based login page
XHR POST to IdP with credentials (modulo an MFA challenge)
IdP returns an access token, React app subsequently uses that for future requests to the API
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..
You can create a React based Identity Server login page for Authorization Code flow with PKCE instead of using MVC UI if you want. It is just extra work and complicated. I would recommend you just style the Identity Server MVC UI to look exactly like your frontend SPA. This is the simplest way and the path I took when I did a project with Identity Server(with Angular as front end).
Related
I did dome research about WSO2 OIDC but what I found is rather than use my own login page I can only just customize the login page only
Is there any method to use my froundend page to let me have the full control of the layout
Contrary to what you have mentioned, you can actually modify the layout of the SSO page by tinkering with these two files:
https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/login.jsp
https://github.com/wso2/identity-apps/blob/master/apps/authentication-portal/src/main/webapp/basicauth.jsp
However, if you still insist on using your React app, you can use the password grant to build your own React-based login page. But there are several caveats:
You cannot use multi-factor authentication or social media login since the user is not going to be redirected to the identity server during the authentication process.
It should only be used with first-party applications that you trust.
It compromises the security of your application and it is not recommended to be used by OAuth 2.0
Personally, I would not want to use this grant but I wanted to let you know this option exists if you insist on handling authentication yourself.
Authentication endpoint (login portal) is tightly bound to Servlet technologies as of the latest release. You can find how to host it external on any servlet container (e.g. Tomcat) here
There is an improvements suggested to allow it to developed using any technology including ReactJs, exposing API set for authentication flow. However this has not been prioritised yet.
Hence you can use the existing Servlet/JSP way for your research. This may seem bit harder than using ReactJS, yet is the best way available at present.
I know that OAuth 2.0 Authorization Code with PKCE Flow is the best practice of OAuth. We plan to use it for our WEB application.
But I don't understand how can I use this flow for native UX my mobile app without using a browser for authentication (https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472)
Using a browser is unacceptable in our case.
The mobile app has a Login Page where user enters their сredentials, 3-th-party authorization is not.
Is it possible to use Authorization Code with PKCE Flow or should I use the OAuth2 Resource Owner Password Grant in my case?
Are there any other alternatives?
There are two main options here:
1. AUTHORIZATION CODE FLOW + PKCE
This is typically done by plugging in AppAuth libraries and using a Chrome Custom Tab or ASWebAuthenticationSession window so that the user experience feels integrated. These are the main advantages:
Login tends to be more user friendly, and features such as password autofill and single sign on across multiple apps works best
You can potentially support many authentication options rather than just user name and password
It will do better in third party security reviews (if applicable) since it is the standard option - eg Google use it for mobile Gmail
There is a learning curve in implementing it though. Also, it has a prerequisite of using an Authorization Server and externalising the login user experience. This can be difficult to manage politically at some companies.
2. RESOURCE OWNER PASSWORD GRANT
This is also possible as a short term solution but is deprecated in OAuth 2.1 and will fare less well in security reviews. It limits you to password based sign in and can sometimes result in long lived access tokens (if refresh tokens are not supported). Plus points are that you are more in control of branding and login screen behaviour.
PRACTICAL NEXT STEPS
If you want to look at some working apps that use Code Flow + PKCE, feel free to run the apps from my Quick Start Page. Maybe then you can make an informed decision based on factors such as User Experience and what is most important to your stakeholders.
If you are just looking for first-party signup and login, Ory Kratos is an open-source solution that does not use OAuth2.0 for first-party flows.
So you can skip the complexity of OAuth2.0 entirely!
A nice bonus is that you don't need to open a browser window (as you always have to do with OAuth2.0, there is no way around it).
Check out this tutorial for some concrete implementation details:
https://www.ory.sh/login-react-native-authentication-example-api/
I'm a newbie React developer (long term ASP.NET MVC), in the early stages of our first real React SPA project (React UI on a .NET Core 3.1 Web API). I'm looking at authentication/authorization, seeing what's available.
I have scaffolded up a React SPA with authentication (i.e. login). It's... alright.
We need ~roles in the client, for some selective access to features.
There is an authorization (as distinct from authentication) system in ASP.NET Core Identity, with scaffolding and so on, which might be nice in that it's (a) done for us and (b) tested security. But all the code samples are for server-side stuff, Razor pages and MVC. Nothing for SPAs. Searching Stack Overflow I see very little about using the authorization with SPAs, and a fair number of unanswered questions.
I wonder how one would actually use this in an SPA if it's possible. I guess you would want the server login response to also give the SPA an authorization token saying "Sandra has these roles". The GUI would note that and show/hide things accordingly. Is returning roles with login results actually a thing the scaffolded Microsoft identity system can do?
Our backend already has an established authorization system it uses on normal API calls. It could expose "user A has access to features X, Z, T" as a regular data access method. However, I have been delegated to see if I can do that as part of the login, and have the scaffolding give us a GUI for creating roles and assigning users to them.
So, I guess, I'm asking: what's the sensible approach here? Do people actually use scaffolded ASP.Net roles with React apps, or do they do use third parties, or do roles as general application data outside of security, or...?
To put it another way: would you advise me to continue down this path (scaffolding Microsoft Identity to handle roles for use in a React frontend), or do something else?
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 product ecosystem consisting of multiple products i.e: An angular app, a website and a hybrid app all powered by node back end.
So, now I want to add a single authentication and authorization to the whole ecosystem also it needs to be modular and scalable.
Plus I'm following a 3-tier architecture i.e: [APPLICATION] --> [API] --> [DB], only the API layer having access to the DB.
Now I also want the Authentication and Authorization to be another app in the ecosystem that can be plugged into other apps and used without much setup.
Also since It's(Authentication and Authorization module) another application I don't want it to access the DB directly, I want it to make API calls that do it, plus it shouldn't use third party auth schemes like auth0.
Important thing being none of the applications other than the Authentication and Authorization module should have any auth related logic in them.
Basically this should be the module than when plugged in allows Authentication and Authorization and integrates seamlessly.
Is this setup possible? If so how do i go about it? If not how is Authentication and Authorization achieved in other such production grade ecosystems?
Thanks in advance!
Authentication can definitely be thought of as a module; just a widget with a database backend that takes in credentials and spits outs error messages or authorization tokens. Authorization, however, is a bit more complicated; once you have received those authorization tokens, you need to decide what they mean.
Without knowing anything about your applications, I would say that you would need to create a mapping of privileges to user accounts for each application. This is trivial if you just want to restrict users from accessing each other's content, but gets harder if you want to give some users more (or less) power than others. If that is the case, than I'd suggest you use some form of role-based access control. You can find some more discussion on how to handle authorization here.