We want develop few different services (React Apps) with the same users database and Rest API.
Some users might have access to APP 1, some for APP 2, some for both depends on their role.
We decided to go on multiple subdomain apps method.
We want SSO so only one page/app to authenticate all the apps and not a local login component for each app. using JWT mechanism in our backend.
STRUCTURE:
AUTH FLOW:
There are two main problems in this flow which are marked as 1 and 2:
Lets say i go to the login app and log in, getting accestoken from the backend.
How do i deliver the token to app1.company.com? should react login APP redirect with token in url param?
local storage is subdomain scoped.
iframe has problems with Safari.
I don't wanna save jwt in cookies for now because the flask REST can serve non-browser retailed clients.
Lets say the user want to go to app2. if we aren't able to share the token from app1 with iframes or any other method, then this app should be redirected to login and make the process again as app1, which is fine for us.
But is this really the way? if token is invalid anymore and we get Error from backend, should we redirect to the login app in the other subdomain (embed the url we wanna go back to after login success)?
Can i just use 3rd party Open id connect service?
Should i consider microfrontends approcah to make the all the "apps" on the same domain?
How "Attlassian" as an example handles this process?
What am i missing and what is the best way to solve this flow?
Lets say i go to the login app and log in, getting accestoken from the backend. How do i deliver the token to app1.company.com?
It is not a problem that login.company.com delivers the token as a parameter in the URL, because the site can verify the authenticity of the token by verifying the digital signature or with a specific endpoint in the central authentication domain. This is how openid/oauth2 does it using the "implicit" flow, although they also allows to send the token as POST, or use a 2-step flow ("authorization_code" flow)
Lets say the user want to go to app2. if we aren't able to share the token from app1 with iframes or any other method, then this app should be redirected to login and make the process again as app1, which is fine for us. But is this really the way?
You can share the token between domains using an internal iframe, but in your case I would recommend that each domain use its own token.
if token is invalid anymore and we get Error from backend, should we redirect to the login app in the other subdomain (embed the url we wanna go back to after login success)?
Yes, in the number 2) of your drawing, just redirect from app2.company.com to login.company.com and follow the same flow as in 1). You will need some type of cookie on login.company.com to avoid requesting credentials from the user again
Can i just use 3rd party Open id connect service?
Yes, you can use an external OpenIdConnect service, or deploy at login.company.com an OpenIdConnect server like IdentityServer or KeyCloak
Should i consider microfrontends approcah to make the all the "apps" on the same domain?
It is not necessary having a central authentication domain
How "Attlassian" as an example handles this process?
I don't know exactly how Attlassian does it, but currently most web services support OpenIdConnect
Related
In a .NET app I can add authentication and authorization using web.config and/or IIS. I can also use [Authorize (Roles = "RoleABC")] in a MVC app's controller or action. And even extend the AuthorizationAttribute
I'm looking into creating a React app for intranet use, and reading these tutorials (ReactJS and MS), but can't find authentication/authorization details.
Even though the app will be Single Page App, I still would like to authenticate and authorize users for certain options within the app, just like I can do in MVC app.
Is the only option to do that way is creating Blazor app instead?
For authentication and authorization, you should use auth tokens (like JWT). Your backend should create an auth token when a client logs in to the system and sends it to the client. Your server also should send the authenticated user information to the client (react app) so that you can render correct pages according to the user type. For example, you can render the admin page for an admin type of user, and the guest page for a guest type of user. You can save this user data as JSON in Redux. Hence you can access the user data from any component of your react. Also, in your backend, you must restrict the endpoints according to the auth token which is sent by the client. In the backend of my app, I follow the below steps:
Authentication check -> Authorization check -> controller (endpoint) -> result
React isn't opinionated on this, so it's up to you to design the implementation. A basic way to do this is:
Log in and obtain an authorized JWT token from the backend and include the account ID when you sign it
Store the JWT token in localStorage, store the account info in Redux
Conditionally limit routes based on account info (ie. admin group) on the front end
Have every auth-required API call include the JWT token in the x-auth-token header, then on the backend use middleware to check if it's still valid. You can then also decode the account ID in order to check its privileges so that you can limit API access
This may be helpful: https://medium.com/#faizanv/authentication-for-your-react-and-express-application-w-json-web-tokens-923515826e0#5f52
Not sure whether you still need this - I personally feel we should have something bridging the authZ gap between server and client to make it easy. So I spent a few days on a github project for this purpose, here it is: authzyin.
What I tried to do is to leverage policy based authorization from asp.net core - which I think it's very cool - and automatically bring the same definition to the client to use in React via hooks.
For authentication I am using msal.js against AAD - so authN is done on the client and jwt bearer token auth is used for all requests.
It has a client lib and a server lib which can be used together or separately. Of course it might still be lacking some features - please feel free to take it as a reference (contribution is also welcome).
We have two web application let's say http://app1.com and http://app2.com hosted on the different domain.
App1-> communicate to OAuth server to get the access token, which we store in browser's local storage.
App2 -> simple frontend app developed in React.
Now we want to navigate to app2 from app1 with the help of an existing token. Which will be then used to call the APIs from app2.
Problem: As we can't access local storage from a different domain. so we have to get the access token again after redirected to the new application.
Current approach:
We are passing encrypted username from app1 while redirecting. Then we make a call to Oauth server with that username to get access Token.
I am sure there will be a better way to achieve this. Any reference pointer will be helpful.
Thanks in advance.
You don't need to pass anything from pp1 to app2. Just use standard OpenID connect flow in app2 (implicit one for React). App2 will redirect user to used Identity Provider (IdP), where user has already opened session, so IdP will redirect browser back to the app2 with own access token for app2.
I am trying to protect a react.js spa app with adal login and authenticate with .net core wepApi.
I am able to get JWT from azure invoked by react SPA (using react-adal module) and retrieve basic user information.
Now the joy begins
As most MSFT examples are based on their mvc approach, they have a password to sign token in the webconfig file, which is not accessible for frontend application.
How then I could sign the JWT token using a password without pushing it to the SPA app as that could be read in a web console?
One of my ideas is to initiate login in the SPA, then use a webapi endpoint as a redirect link (and provide a connection id in state field) and then by ajax I could do redirect on the SPA, but still there is no signature on the JWT.
my partial solution at the moment is:
have react-adal used to validate if user is logged-in
when there is no token, then react-adal authenticates, but redirection is on a special page when I am grabbing the token and store it in database. The trick here is: there is a need to change hash to query-string to grab the token serverside (as all after # is not forwarded to web-server), so a simple javascrip that replaces # with ? and redirects to another endpoint.
then redirect to the main application
As the URL is only used for redirects (after adal login ) - that is a typical man-in-the-middle scenario, but gives an ability to generate own token.
I'm having I think, a misunderstanding of concepts related with Oauth2 protocol. Right now I have 3 applications:
Frontend developed in React
OAuth2 server developed in Golang (not finished)
Another backend app, let's call it: Bussiness Logic app
At first, the user from react can login in the system using the OAuth2 server, the OAuth2 server sends the token and everything's perfect.
Now, when from the the react app some request is send to the Bussiness Logic App the token is also send in the headers. My question is: having the token, should I be able from the Bussiness Logic App to get information fo the user making a request to the OAuth server? is it allowed in the OAuth protocol?
The thing is that I need to know in the Bussiness Logic App which user is logged in, if it's not allowed, how should I fix it?
No.
OAuth 2.0 NOT an Authentication protocol.
If you need Identity Information you need to use OpenID Connect (which is built on OAuth 2.0)
With OpenID Connect you are provided both an Access Token and an Identity Token. The Identity Token will contain "basic" profile information about the "user". The Access Token may be used to obtain more detailed information about the user from the userinfo_endpoint.
i've a desktop site based on wordpress.
Mobile version is on a subdomain and is developed using angularJs (ionic).
I'm trying to figure out what the best solution to authenticate mobile version users using wordpress wp_users credentials.
Thanks in advance for any advice.
1 - Basic Auth: The easiest, This one is not recommended for production since your users will be sending their credentials with each request, only use it over https.
2 - OAuth: This one is secured but might not be interesting because users will be redirected to WP to login then redirected back after login success, here is a decent tutorial for it.
3 - JWT Auth: This one is interesting because it only sends user credentials once, when login succeed you will get a jwt token which will be used instead of user's password in each request.
For your app purpose I recommend implementing your own authentication method, make a plugin for that, it should generate a secret token and save it in user session, it should also block any request that doesn't include that secret token.