Which is a common way to implement oauth2 auth on the angular-based single page application?
Is it possible to implement it without page reload? If not - what is a best way to transfer auth data back to angular code from the page?
The authorization server must provide an api to authenticate user and return access token without redirecting. I will take facebook as authorization server and resource server in this example for easier understanding. The flow is like this:
Your user clicks on a button on the page.
Since this is SPA built with angularjs, the browser sends an ajax to
your server to get data.
On server side, you find out that this action requires data from
resource server (facebook), instead of redirecting the browser
to resource server as we usually do, the server sends a response
with a custom status (or any information indicating that this action
needs an access token) to the browser.
On browser, when you receive response from server in your ajax
success callback function. You can check the response and find out
that this action needs an access token
The browser first tries to get this access token from resource server
(if the user is already logged in). When working with facebook using
FB javascript SDK, we usually use FB.getLoginStatus function.
a. If we can get the access token in the success callback (the user is
already logged in), just send this access token to server to get
data (using ajax).
b. If the user is not logged in yet, use javascript
to prompt the user to login by rendering a login button and the user has to click on it. When working with facebook using FB
javascript SDK, we usually use FB.login function when user clicks on the login button. After
successful login, we will receive the access token in the success
callback and just send it to server to get the response (using
ajax).
There is no page reload because all actions are done with ajax (without browser's redirects)
Related
I've been reading up on token based authentication for a project that's part of my trainee-ship. My task is to implement some sort of user authentication and we've settled on token based authentication.
Now I get the basic principles, like passing the token in the xhr header for xhr requests. But I do not understand how you would pass the token on an initial page call.
Let's say we're working on a single page application with a navigation bar that has a login button for users that are not currently logged in, and a profile button for users that are logged in.
Seeing as that navigation bar is delivered on the initial call of the website, how do I know how to serve the right button to the user? From what I can gather I can pretty much only authenticate on xhr.
Do I have a misunderstanding about token based authentication?
A little clarification:
Assume a User already is logged in and has received a token from the Server.
He then closes the Tab and later goes to my app again.
At this point, server-side I do not know the user, as I could not have sent the token at the initial request.
A coworker suggested using AngularJS' onload to send the token after the initial page load to verify and get my JSON data from the server, which is then used to create the app with Angular
Also the point of the project is to not use an existing library like JWT, so I can actually grasp the concept and the inner workings of such mechanisms.
I'm setting up an HTML5 and JavaScript web application to consume Azure Mobile Services tables using the JavaScript client library. I've managed to get authentication setup successfully with the MicrosoftAccount identity provider. On load, my application checks if the user is already logged in, or if we have a token and username stored locally. If true, I hide the login button, and display the logout button, and proceed to load application data.
My problem is that when a token that is stored locally expires, my application still thinks the user is logged in. Therefore when I request table data, I get a 401 Unauthorized HTTP response.
Is there a graceful pattern to renew an expired token without burdening the user with relogging in every time their token expires?
You will need to log the user in every time, unfortunately. The token must have a lifetime associated with it. On some client platforms, you can get much longer lifetimes via single-sign flows, but these are generally not available for HTML. The common pattern is to, upon receiving the 401, retrigger your login code. Here is a blog post showing the approach for the Mobile Services Managed SDK. The same concepts should apply for JS.
I am trying to implement form authentication in my ajax application.
The problem I have is that when the session expires I get 302 code which redirects me to a login page I specified in web.xml (and it messes everything up refreshing the whole app to login page).
What I want to do is to get a "not authenticated" (401) code, then display the login form in a popup window and when the login is successful continue with what I was doing.
here is a picture of what is going on:
and the docs
http://docs.oracle.com/javaee/1.4/tutorial/doc/Security5.html
basically, I want to display the popup instead of redirect to login page and then don't do the redirect to the resource but do my update in AJAX way.
From what I understand it couldn't be done only on the client side since the redirect can't be avoided (see here: redirect info), I would need to write some kind of logic on the server to prevent redirect, see here for detail about doing it in IIS: IIS implementation
P.S. So far this: http://www.oracle.com/technetwork/articles/entarch/session-lifecycle-096133.html looks like the most promising way to implement it. The class is deprecated, but I can't find the new one and think it's the only way to do it for Weblogic.
This is not an easy way but still it works
You have a form in your page which is filled by the user.
User clicks submit button.
An ajax request is sent to the server.
The server side implementation can check whether session exists or not. and accordingly you can send a response code 401..(response.setStatus());
This 401 can be checked in client side using ajax --- xhr.status
If response is 401 you can show the login form and hide the current form. using js and css.
User fills in the login details and clicks submit..
You can do the same server side check and client side check for the status of that login request.
if login is successful then you can you can submit the first form using ajax or js..
You may need to use servlet authentication filters as described in weblogic.xml Deployment Descriptor Elements
Below tutorials may help you:
oracle Servlet Authentication Filters
Using servlet filters for user authentication
Writing Servlet Filters
You could use a heartbeat checking with an ajax request to your server to any resource that needs to be authenticated to get it.. if you cannot receive this resource so means that youre not logged in.. so you could send another authentication request an go on with your rendering..
see this article.. http://ajaxpatterns.org/archive/Heartbeat.php
so your checking routine of authentication would be implemented..
You need to push to page and not poll. So you need Strophe and your session handler connected. When session expires signal is sent to Strophe instance that is running in your web app and after that it is easy to do popup or whatever.
For all real time stuff I am using Strophe!
This is book on this metter and this is link for Strophe, also this is link of php xmpp class.
It will take you couple of days to figure out this but it is couple of days well spent!
If you read carefully book and go to examples, with just basic javascript/jquery understanding you will be able to develop powerful web apps.
I know you're trying to do FORM authentication with you ajax application but is it really needed?
BASIC authentication works simpler and transparently for ajax requests as it is handled by the browser, not by your app. But I admit/understand that a popup is ugly.
With BoilerplateJS setup, what is the recommended way to handle authorization and authentication?
Obviously on the server-side you'd check cookies etc to know who's logged in. But, on the client, how would you know if a user is logged in and what their username etc are?
I will share how this was done in one of the projects that used BoilerplateJS. On this project we used OAuth 2.0 for authentication.
We had a separate login page which was NOT using BoilerplateJS OR complex JS. The reason to keep it separate is that authentication may depend on URL redirection, which is not handled best with JS.
Once user is correctly authenticated, we receive the auth_token of the server session and store it as a JS variable. We used 'settings' of global Boiler.Context to store this token. Since settings are inherited to child contexts, we were able to access it from any where.
For authorization purposes, then we then downloaded a simple ACL for the logged user that contains the authorized access keys. These keys were just for client validations to show/hide controls. Real authorization was performed on backend services.
We wanted the BoilerplateJS components to be fully self contained including authentication of it. Therefore if a particular component's viewmodel receive an unauthorized 401 HTTP response from server (either not logged-in OR or session expiry) we rendered component differently there, without redirecting user to the login page.
Since we did not redirect, user was able to make use of other information on the page even the BoilerplateJS component was not actively displaying it's content. We had a rendered some error information on the component with a link to re-login.
Handling of this was done via a generic error handler we created. From component.js, we pass a error callback function to our viewmodel (you may have this on context itself too). This callback function is used by the viewmodel to notify any error occurred within it. In the case of 401 HTTP code, this handler is invoked asking component.js to render UI with error information and a link to re-login.
User clicks on the re-login URL to get back to the login page. This URL contains a back reference to the originated URL, such that user is able to get to the page where he was after authentication.
I'm currently implementing the Javascript Facebook login API.
Based on the callback response from Facebook, this client side script then sends a request with query string parameters to a URL on our site. Based on the email in that URL, the client is authenticated.
This is not secure. No other token that we can verify against is returned from Facebook (as far as I know), and we are expected to log the user in based on an email in a query string parameter, and no password.
I'd like to add another query string parameter that gives us some sort of assurance that the query string data came from a JavaScript redirect following the response from Facebook.
I'm thinking that this should be some sort of hashed value created by a client script that I can compare against server side. However, every resource used to create this secret key would be available to an attacker, via client cookies or through inspecting the client script.
Is there a common and secure approach to this problem that I can use?
Facebook apparently uses OAuth. Without getting into too much details (which you could find in relevant OAuth and FB documentation), OAuth operates with a secret shared between your server and the service provider (Facebook, in this instance), which is never revealed to the frontend Javascript, and is used to confirm if the callback you receive is genuine.
Pass Facebook a unique callback URL each time you authenticate user.
This URL should contain some security token, which, if present, will identify the authenticity of the logon attempt.
You can add a state variable to your requests to Facebook. This will be returned to you by Facebook to validate your request.
https://developers.facebook.com/docs/reference/dialogs/oauth/