I want to ask advice for a recommended or standard way in implementing SSO login based on a FrontEnd/BackEnd architecture.
Currently, I will need to implement a 3rd party SSO Login. The process is as below:
User click "3rd party login" in my website
Route to 3rd party interface for SSO login.
Once done login, redirect back to my website
FYI, my system architecture consist of a frontend (angular) and a backend (rest api - stateless). Based on above case, I can think of 2 type of way to integrate:
Way 1
User click "3rd party login" in frontend
Route to 3rd party interface for SSO login.
Once done login, redirect back to backend
Validate the request and set token, and backend will redirect to my frontend
Way 2
User click "3rd party login" in frontend
Route to 3rd party interface for SSO login.
Once done login, redirect back to frontend
Frontend will make a call to backend to validate and get result/token
If validated successfully, frontend will redirect to the home page.
The difference between way 1 and way 2 is that the "redirect URL". When SSO login complete, it should always route to frontend or backend?
Please do advice me on the recommended/standard implementation.
Btw, I tried to check online but didn't see any suitable advice. If you found any, please share to me. Thanks again and appreciate the help.
I am now aware of the recommended/standard way for implementing the scenario.
However, I have worked on a project where we have implemented the sso in the frontend. But in my opinion, it depends upon your project.
If so is implemented in the frontend, they have to pass the token with every call to the backend. The backend has to check the token every time so that no one is able to make calls to the backend directly for example from the postman.
If so is implemented in the backend, the frontend won't have to pass the token. And as the backend maintains the token the external calling of api is already handled.
Related
I am setting up a login system in auth0 for a React Typescript application. Due to how the application works I am using the PKCE flow for authentication and authorization to get access tokens and refresh tokens. So far I have implemented the flow by adding a node js express server that fetches the access token and refresh token from auth0 once we have the authroization code after logging in through the /authroize endpoint on auth0. However the problem we have now is that we cant implement our custom UI onto the login page since when we hit the /authorize endpoint we are sent to the login page hosted at auth0. We would want to set up our own login form and send over the details to auth0 in order to fetch the authorization code. Is there a way to login through our own login page instead of using the one hosted by auth0, by for example hitting the right endpoint in their api to fetch an authorization code? The only other option I have seen is by changing the HTML under branding in the application dashboard but I have also read that auth0 does not recommend doing this.
I have also previously used the auth0 js SDK and there I was able to use our own custom page for login, however that SDK uses the implicit flow which does not issue refresh tokens and cannot therefore be used. In the other SPA sdk, you cant add your own UI for login since that redirects you to auth0 as well.
Assuming that you still use the Node.js server in addition to the SPA, you can ask the user for username and password, send it the Node.js server. Using the Resource Owner Password flow, the Node.js server can then request the access, refresh and ID tokens.
Please study the security implications carefully, in particular related to this authentication flow.
By implementing custom login UIs, you lose many things: hardened security of Auth0 servers, easy configuration of authentication methods without changing the application, use of ready-made Auth0 SDKs etc. I would carefully consider if it is worth it.
I am trying to integrate third-party (TP) APIs (https://api.icicidirect.com/apiuser/ICICIDirectAPIDOC.htm) in my react/node.js app. The APIs use OAuth 2 for authentication and after authentication.
The sequence of actions is something like this - a user clicks on the TP image on my react app and gets redirected to the TP's login page. After authentication, TP does a redirect with a form post. Based on my current understanding, only the backend server can host a post method where the TP can post the form. From here, it is not clear how to trigger the react app to detect that the user has logged in and render their dashboard.
I have two questions:
Assuming I register a frontend URL as the redirect URL, is there a way I can capture this form post on the frontend?
If #1 is not possible, what's the most elegant way of letting the frontend know that the login was successful, after receiving the redirect on the backend?
I would check a couple of things since it seems your app needs to use OAuth tokens as well as to sign in:
Is PKCE used and / or a client secret? This will determine whether you can complete the login in the browser and swap the code for tokens.
Can you add a response_mode=query query parameter when you trigger the redirect, which will make the response a GET (if the provider supports it).
Q1
The usual solution is to return the authorization result on this type of URL, which is SPA friendly. The browser cannot receive POST requests.
GET https://www.example.com?code=xxx&state=yyy
The SPA can then perform one of these actions and get tokens:
Exchange the code for tokens if PKCE (a runtime secret) is used
Otherwise proxy the request via an API, which attaches the client secret
Q2
If the provider only supports POST responses you can can write a small amount of code in the web host (as a workaround) when it serves the index.html page. This could check whether it is a login response, and if so trigger a redirect with the above query parameters.
WEB HOST RESPONSE PROCESSING
Do the login response processing and code exchange in the web host, then redirect the SPA to a location such as https://www.example.com/loggedin, which will notify the SPA so that it can update its UI state.
ALTERNATIVE OPTION: OUT OF INTEREST
The above could require quite a bit of code in the web host, which could potentially impact your web deployment options, eg if you wanted to serve web static content from a Content Delivery Network.
So another option the web host could use is to just perform a redirect to https://www.example.com?code=xxx&state=yyy. The SPA could then call an API to complete the OAuth processing. This requires more security due diligence (eg ensure that PKCE is used), but is how a Back End for Front End SPA solution would work.
I've been studying the OAuth 2.0 authorization code flow and am trying to write a React application with an Express backend that displays what a user would see on their own Instagram profile. I'm trying to do so with minimal external libraries (i.e. not using passport-js) and without bringing a database into the mix.
This is my flow as of now:
Resource owner clicks an <a> tag on the React application (port 3000) which redirects them to the /auth/instagram endpoint of my Express server (port 8000)
res.redirect(AUTHORIZATON_URL) sends them to Instagram's authorization server
Resource owner consents and the authorization code is sent back to the predefined redirect-url /auth/instagram/callback with the authorization code set as a query parameter
I strip the authorization code off the url and make a POST request to https://api.instagram.com/oauth/access_token to grab the access token
Now that I have the access token, how do I reach out to the React frontend to let them know that everything worked and that the user was successfully authenticated?
From what I've read, this is where the idea of sessions and cookies come into play, but I haven't had luck finding documentation on how to achieve what I want without bringing in third party libraries.
In the end, I would like for my app to support multiple users viewing their profiles simultaneously. Since I imagine passing the access token to the frontend defeats the purpose of securely retrieving it on the backend, I'm guessing I will somehow need to pass a session id between the frontend and backend that is somehow linked to an access token.
Any ideas as to what my next steps should be are greatly appreciated, as well as any articles or documentation you see fit. Thanks!
Since you're doing the OAuth authentication on the server side, you have to pass some parameter to the redirect_uri, identifying the user session (see: Adding a query parameter to the Instagram auth redirect_uri doesn't work? );
When the redirect uri is called from the authority server, you will know which user was authorized. To notify the browser there are two options: 1) Notify the client using web sockets; 2) Pull the state from the client using a timer triggered function;
I'm working on an application using sails. web and mobile.
I want to use CSRF protection that sails provides when the app is visiting on the web. And if a request is send by the mobile app. send with the payload a jwt.
On the sails' documentation I found a property csrf.routesDisabled that disabled the CSRF for some routes. But that is not what I want. I'm trying to find a way to for example, check if the parameter jwt is send in the post request. And if the parameter was send then check and validate it. else, check for _csrf value of the form. Is this possible?
or the csrf protecction works before any information is send to the server?
my better choose is use jwt in the web app too?
any other good idea for solving this problem is welcome
thanks
Sounds like you've built the web app with SailsJS and you're trying to reuse the controller actions as REST endpoints for external applications.
Really what you should do, is decouple the data access from the front-end. Have an isolated REST API - using token authentication - which is used by both a web front-end (and any other applications).
For example, I'm currently working with a SailsJS REST API, used by an EmberJS front-end and an iOS app. Both front ends login using user credentials, in order to receive an authentication token. This token is then used for any future requests. A policy locks down all but the login authentication endpoint, to validate the token
I'm facing a problem related to oauth authentication using NodeJS. The main concern is how to connect all to my current architecture. Lets me explain it a little bit.
I have a Cloud API which is a REST API to serve and manage the data. I also have the web client developed in ReactJS (an SPA). My main goal is to allow social authentication without redirect or without to leave the page. For this, I'm using HelloJS and the oauth proxy in the same Cloud API.
Taking for example my Facebook App, the workflow is like:
The user clicks signup with Facebook
The oauth proxy serve as "handshake".
Facebook sends back the token to the web app.
At this point, this approach is working perfectly for me. My main concern is how do I send the token to the Cloud API for registration?, obviously I could add a middleware in the Cloud API to automatically register the user in the database, however I still need to invoke the authentication from the web client in order to exchange that token for a JWT token.
Yes, I'm using JWT for communication with the REST API. I would like to allow local registration and social registration (Facebook, Twitter, and so forth).
It seems odd to me to trust in the token received from the web app without ensure that it is real and not expired. I thought to check it with passportjs.
Advices or recomendations?
Thanks.