Good afternoon. I'm creating an authentication system via SSO.
Let's imagine the following scenario:
Site A: forms.nso.imm.pt (Backend: backend.forms.nso.imm.pt)
Site B: auth.aettr.pt (Backend: backend.auth.aettr.pt)
Now I want a user, when clicking on the login button on Site A, to be redirected to the Authentication portal of Site B, and with that the user can authenticate himself with the credentials of Site B. For this, when the user clicks on login , currently the frontend of Site A, communicates with its own backend, which in turn communicates with the backend of Site B, to create an authentication session token, then this token is returned to the backend of site A, and in turn returned to the front-end of site A, which in turn forwards the user to the frontend of site B, passing the previously created token via query string. But it just creates a vulnerability. If a malicious user creates an authentication session, copies the URL and sends it to the victim, the victim sees that the site is real, because it is indeed an authentication, and logs in, then the malicious person just needs to refresh and he will be redirected to site A with the victim's session.
For that I've already tried on the backend of site B along with the authentication session token, create a uuid, record it in the database along with the token, and automatically create a cookie with that uuid. So when the user opened the front-end of site B and it was going to validate the authentication session token, if the cookie did not exist or was not the same as what is in the database, he would not let the login, because a victim would never have the cookie created at the time of the authentication session token creation process. But unfortunately this is not possible because I cannot create the cookie, because the user "does not open" the backend domain of site B.
Does anyone know any other ways to resolve this vulnerability via cookies, or otherwise? (Except browser fingerprint)
Related
I want to implement a feature in which there is a central login site lets say: https://example.com , and when user enter login credentials in this page and select from dropdown on which sub domain user wants to log into, the user gets logged into that subdomain like https://abc.example.com.
I am using MEAN stack and jwt token for authentication. JWT implementation is applied in standard way in which first: request is sent to "/authenticate" and then token is returned which will be stored in browser local storage.
I have successfully done one site authentication ie. login from https://example.com and logging user in that domain, but now I want to implement like this flow =>
On login page of https://example.com :
User can select an option from drop down in which subdomain to login
After that user enters login credentials ( these credentials can be different or same for all subdomains )
User gets redirected to dashboard page of that subdomain ( with JWT token stored in the local storage of that selected sub domain )
Above is the flow I want to be implemented but can be changed if other flow achieves the same result
I have searched questions and blogs regarding this topic:
I have gone through SSO ... but that is not what exactly I want; because SSO is like login in one subdomain and it gets logged in everywhere else... but I want to login from a single login page to subdomain's dashboard page based on user selection.
How I have thought of implementing this (not working) :
I will first send "/authenticate" request to https://example.com with parameter like
{ username: "alice", password: "****", subDomainUrl: "https://abc.example.com"}
My nodejs backend will authenticate and return me the JWT token. Now I will redirect to that subdomain(https://abc.example.com) and send this token from https://example.com to https://abc.example.com and somehow it will get stored in this subdomain's(https://abc.example.com) localstorage. After it is stored in local storage I can easily do my other work.
So how to implement this? Is the above approach practical; if then how to properly do it? What is the best way to implement these kind of architectures? Any help will be great, Thanks!
I suggest you first send /authenticate request from https://example.com/.
It will be validated by nodejs backend and then generate JWT token and redirect to the new subdomain including token.
http.get('*',function(req,res){
res.redirect('https://abc.example.com?token='+JWTtoken);
})
You can fetch the token from the subdomain and store in your local storage. Further, you can use this token for your api authentication.
Let us consider I have 2 websites A & B. Now I have logged into A using my credentials & a token has been generated. I have stored the token & Client IP along with the token's expiry into the DB. Now there is a button inside A which will redirect me to B. I want B to be authenticated with the same token so that I don't have to manually log into B.
Also I cannot skip the login page of B every time as one might directly log into B (without A) at that time login is required .
So how can I get the token once B is launched only via A.
It sounds like you are trying to implement SSO (Single Sign-On) flow. Let's say we have two sites "site-a.com" and "site-b.com". There multiple ways we could go about building SSO, the easiest would be to have a shared "gateway point" (let's call it "sso-site.com") that implements the following flow:
The user comes to site A
They get redirected to the SSO gateway
SSO gateway checks for the token. If found, it redirects the user back to the site A. If the user needs to login, they are redirected to the login page and then back to the site A.
Any link to site B will put the user through the same "gateway" (same authentication flow as above)
There are multiple ways the gateway could control the flow between sites, it all depends on the business logic you are building. The key part here is that the site navigation is forced through a central gateway that makes sure that the users who should log in are logged in and do so only once.
Hope that helps!
I have read several articles about sso but could not find an answer in my mind.
I have a scenario like below:
Scenario:
My company wants to have sso mechanism using jwt.
Company has 2 different domains like abc.com as abc and xyz.com as xyz.
Also there is a masterdomain that manages clients authentication.
User X wants to log in abc at first.
abc sends credentials to masterdomain and masterdomain authenticates user then create a signed jwt in order to send back to abc.
abc keeps this jwt in a cookie.
After a while if a login to abc is attempted at the same computer, system does not ask for credentials and automatically login the user.
Question:
If user tries to open a page in xyz domain, how does the system understand that the user loggedin before? I mean xyz domain cannot reach the cookie of abc which has the jwt. What information should be sent to xyz that indicates the user X is trying to login?
Thanks in advance
You can store the JWT authentication token in a cookie / localStorage of a intermediate domain connected to the home page using an iframe
Scenario
abc sends credentials to masterdomain and masterdomain authenticates user then create a signed jwt in order to send back to abc.
abc masterdomain keeps this jwt in a cookie.
After a while if a login to abc is attempted at the same computer, system does not ask for credentials and automatically login the user.
Finally when the user enters in the second domain xyz, the jwt is recovered from masterdomain storage using the iframe, and automatically login the user
CORS is not a problem because masterdomain.com have access to its storage and communication between iframes is allowed if origin and destination are recognized (see http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage)
To simplify development, we have released recently an opensource project cross domain SSO with JWT at https://github.com/Aralink/ssojwt
User Login Process by Soundcloud Connect button
Press the button on the website and start a session with random token generated by api server without authenticating of the user on Soundcloud.
User is redirect to the Soundcloud authentication page(soundcloud login page).
User should enter the his/her Soundcloud account information.
After pressing connect, a method invoked in the api side to create the user and its authentication according to the params send from SoundCloud. And api server redirects user to home page and the script in clientside sets the token to the headers as authorization to the website.
Now, my concern is starting the session before the user connects through the soundcloud, even thought users can't enter the home page without connecting to the SoundCloud.
Is this technique of authenticating user secure or not? what are the potential attacks?
This approach will make you vulnerable to session fixation.
The attack scenario looks like this:
Attacker tricks user into using a known session key (usually through other vulnerabilities such as XSS)
The user authenticates with SoundCloud, the session key remains intact
The attacker connects to your application with the same session key, thus taking over the session.
While this is attack is not extremely common, it appears in the wild and standard procedure is to always issue a new session key after any authentication takes place.
Yet another Facebook login question.
I am building a one page site that uses Facebook javascript authentication and login. I do not want any page reloads and want to users to login to Facebook at any time. Login to facebook will change my local views (using backbone.js) but shouldn't refresh the page. Although page is not refreshed I want to have server side (threw REST api) to "know" the uid of the user
I have used Server-side authentication before but wish to work only with client side authentication. (for various reasons)
Basically I follow http://developers.facebook.com/blog/post/534/ but my server is node.js
This is how I see the flow: (with restful API)
1. User enter site
2. FB JS SDK login/authenticate user
a. FB SDK has obtained access_token (valid for an hour)
b. signed request is saved in cookie data (fbsr_<app id>)
3. Browser issue any REST API call to Server
a. server looks into cookie to identify uid
Parse the signed_request
Validates sigend_request with application secret
identify uid from parsed signed_request
b. if needed to store long live access token
Server exchange code for tokenA
Server exchange tokenA for longed lived access token (valid for 2 month - fb_exchange_token)
Questions:
why shouldn't I move the access token from client to server instead of signed_request?
is this flow secure?
is it good practice?
Thanks