I want to ask you how does sites like Facebook etc. handle user authentication on the page refresh? I wonder why I don't see any loader when I refresh the page and I'm on the protected route (e.g. my profile settings).
When I create an application I use following authentication flow:
Load the application
Show authentication process loader to the user.
Get user session token from the cookie.
Send authentication request with the token to the backend.
Validate the token on the backend.
Send a response to the client with the status code 200 if token is valid or status code 401 if token is invalid.
Receive a response on the client side and hide the loader.
Show protected route to user if he is authenticated or redirect to the login page when he is not authenticated.
So with such a flow initial loader is a necessity, how facebook is able to omit that?
and welcome to Stack Overflow.
I'm not sure your question is valid - pretty much every page on Facebook requires you to be authenticated (not just the profile page), and authenticated access is a common feature of pretty much every major website; they rarely show loading bars.
We don't know exactly how Facebook is built, but it's a fair guess they use React; you can read up on how to manage authentication on React here.
Your flow is predicated on the assumption that there is an "application" to load, and that the authentication request will take substantial amounts of time. If your token validation is fast, this assumption is probably incorrect. You do see "loading" animations on React apps - if you scroll down your timeline on FB really fast, you see the circle; this is probably partly network, partly retrieving the posts.
I figured it out. It's possible because authentication can be done on the server side using cookies. They validate user token when user enter the page and after this they render desired version of page (different for authenticated and different for not authenticated user).
Related
I have more conteptual question, how exactly should I handle social login in my project.
The use case is that I would like to allow user to login with Facebook, and keep on my backend information about this user (email, firstname, lastname)
I have some proposal Flow, but I'm not sure if it's a proper approach.
Let's say that I have application architecture as above. Now I would like to explain step-by-step full success flow.
Client (Vue application) make a call to AuthProvider (Facebook)
AuthProvider returns access_token
Client after reciving access_token make a call to backend endpoint like /fb_profile with access_token and userID (?)
Backend make a call to AuthProvider to check if given by client access_token is valid or not.
AuthProvider returns information about user. Backend after getting information about user, save it to database and generate new JWT token
Backend returns generated token to user
Now my question is - Is this good approach? Or should i handle it in other way? Like keep more logic to backend part? Instead of make a call to Facebook from Client, maybe should I make a call to backend, and backend make a call to Facebook?
You seem to be on right track. There could me many ways to do the same thing, here is the way which is working for me using vue/laravel/passport/socialite/github.
Trigger redirect in controller from frontend,
Provider(here github app) is triggered in browser with its url using client id/app name saved in back end config/env. Fill out your login details
It will redirect as created in provider and configured in backend-> show it on frontend, in my case its
http://localhost:8080/authorize/github/callback
From frontend now trigger callback in controller, it will check if user details already exist and will insert if its first time user as per logic. Then it will send back access_token to frontend which can be used in frontend for all the operations
DB
The above will be the sequence of the request flow ( same as yours ).
This would be the standard practice we used to integrate with Facebook. In this case, I strictly advise you to use the JavaScript SDK for Facebook.
Refer below link in case if you run into the following issue:
Vuejs component wait for facebook sdk to load
I am working on a website which is developed in react js and I am fetching all data through the API calls. That API calls are visible in the network section of a browser and that API call contains JWT token in the header part of all API call, So it can cause security issue due to that anyone can do that API call with the same header and same URL through other platforms like postman n all.
So my question is that how can I control that no one else is able to access it or how can I hide that API calls from the network section of the browser?
Is there any other solution to solve this security issue?
You have to assign a token to each user. The token will be given to the user upon authentication.
You have to manage access to the page based on the userId and token.
Yo should not use generic tokens for all the users.
Destroy the token upon user logout.
If the user see the token on the network they can only have access to the portion that he is suppose to have access.
This is how I do it, hope it helps.
I am using MEAN stack for developing a web application. I choose it be completely RESTFULL that is stateless. For authentication I am using JWT(Json Web Token) strategy.
Client sends login request to server, server authenticates and sends JWT and user data to the client(here angular 2).I am storing this JWT token in the cookie.
Now my question is how do we store/display user details in the view continuously. For eg if we consider Facebook as restful , after a user logs in, client display user data such as profile image, profile link etc etc.
Since Rest Authentication just retrieves the data, with credentials sent in each request.
How are these user related data retained in the client side. Is it like for each request, user data is fetched from the server and updated continuously in the view.
If yes how or if no then am I missing something.
I know this question might be nonsense to experts, but any advice, suggestion or kickstarter information would be helpful for a novice like me.Are there any best practises for these?
Thanks in advance
Yes, you can fetch user data from server on every request but the right approach is to store it in JWT token as custom claims and on each request get the token from cookie, decode it and get the necessary details from those custom claims.
By the way, you can store user data in localStorage for frequent use.
I am using the standard MVC 5 identity membership so users can be authenticated to use features on my site. Apart from login and register, ALL actions require someone to be logged in.
I want to use PhoneGap to take my mobile ready html and turn it into a mobile application. I intend to use ajax to do all calls to my actions.
How do I do this with the html pages not residing on the same server? How can I log someone in, and then allow them to make calls?
Authenticating users from mobile devices is fairly simple with the new MVC 5 identity membership. Essentially, every HTTP request that is made to your server from a device will include a bearer token to authorize that request.
When your Web API method receives the request, it will identify the user making it via the bearer token. This allows you to use the standard Authorize attribute in your Web API controllers that I'm sure you're used to using in MVC controllers. Here is a basic example of this process, but essentially it goes like this:
Request containing username and password is made to your server.
Server verifies the username/password and sends back a bearer token
Make another request(s) to your server to access data or other functionality, and include the bearer token in each request
Assuming you're doing this from a mobile device, some options for storing the token are HTML5 local storage, SQLLite, etc. There is no "logging in" doing it this way - there is only authorization of requests to the server. Of course, the user doesn't know that so it's very easy to simulate a typical logged on experience. Here's a brief example expanding on the one one above:
Create a standard login screen with fields for username and password and a login button
User fills it out, and when they click login you make an AJAX call to your server requesting a bearer token with the user's entered credentials (should be over HTTPS)
Server authenticates the credentials and you get a bearer token back. From the user's perspective, he is now "logged in".
One way to handle the bearer token from here is to store it in SQLlite or local storage so that is readily accessible for you to grab and include in any more requests to the server that you make. You just have to take into account that the token has an expiration (set by you, see that link I posted), and design your app accordingly. You might want to tighten down your security by only keeping the bearer token on the mobile device only so long as the user is using the app. When they're finished, you remove it from the storage on the device and the user must go through the authentication process (i.e "log in") again when they open the app.
Additionally, this video Securing .Net Web APIs is definitely worth watching.
I am developing a Sinatra web app to which I plan to add a Google sign in capability.
While I am able to understand the Oauth2 authentication mechanism with Google and everything seems to work fine, I have a basic question on maintaining sessions.
I am using the Server side web application flow of Oauth2.
Before I ask my question here is my understanding of the Oauth2 authentication mechanism.
Once the user clicks on the "Sign in with Google" button, the sequence of events are:
The user is redirected to the Google oauth authorization server.
The Google oauth2 authorization server checks if the user has a active
session.
If yes it prompts the user to grant access to my application for the requested data from Google.
If the user grants access then the process of sending back an auth_code and getting access tokens commences.
Based on what I have encountered on the web, the code for all of the above would have to be put in a before filter.
My questions are below:
If I add this code to a before filter, then there would be a round trip to the Google Authentication server for each request that comes to my application from the user.
Am I thinking right in the statement 1 above?
Is this necessary?
Is there some other way of validating session without reaching out to the Google server for each request to my server?
Will this not cause an overhead?
How do web-apps using oauth2 typically handle checking session validity across multiple requests?
Sorry about the longish question and thanks for your patience.
When the user clicks on the Login link and returns with a valid response i.e request.env["omniauth.auth"], you need to store the "uid" in the session and then check for the session in the next requests. Like this
before do
unless ['/login', '/auth/google_oauth2/callback'].include?(action)
unless session[:uid]
redirect "/login"
end
end
end
get "/auth/google_oauth2/callback" do
session[:uid] = request.env["omniauth.auth"]["uid"]
redirect "/"
end
Let me know if it works.