Ember Simple Auth vs Torii

Ember Simple Auth vs. Torii

Simple Auth is more about maintaining session/session events, providing a framework for authenticating a strategy, and authorizing requests. Torii is more about interfacing with these external authentications. So, it’s not as though Simple Auth and Torii could not exist side by side.

You can see how I used Simple Auth and Torii together in this Github example.

      App.LoginRoute = Ember.Route.extend({
        actions: {
          // action to trigger authentication with Facebook
          authenticateWithFacebook: function() {
            this.get('session').authenticate('simple-auth-authenticator:torii', 'facebook-oauth2');
          },
          // action to trigger authentication with Google+
          authenticateWithGooglePlus: function() {
            this.get('session').authenticate('simple-auth-authenticator:torii', 'google-oauth2');
          }
        }
      });

In this example, I’d like to authenticate a session with a Facebook account through the Facebook OAuth 2.0 provider, and Torii would up a Facebook dialogue. So in the example, Simple Auth wraps the Torii mechanism for interacting with Facebook in a Simple Auth authenticator. In short, Torii’s only managing the communication with third parties.

Simple Auth OAuth 2.0 vs Torii’s OAuth 2.0

The Simple Auth OAuth’s 2.0 mechanism is the resource owner and password credentials grant type. That’s a formalization of the process, where you send a username and a password to the server, and in return you get access to it.

That’s not the OAuth 2.0 flow Torii implements for Facebook, as it implements a flow where you have redirects, etc. That’s why Torii would open a new window. As soon as that redirect happens, it uses post message to notify the actual application that the login was successful. It’s very complicated, but Torii handles all that for you.

That said, you really cannot compare that resource owner grant type used by Simple Auth with the one that Torii implements, is they’re two different things. If you would want to implement a Facebook application with Simple Auth and not use Torii for that, you would probably need to use something like the Facebook SDK instead of building that whole thing.

In addition, when fetching user data, you don’t want to use that token for requests against your own API. You would usually change that token you received from Facebook against a bearer token for your own API, which is also where you verify the Facebook token on the server-side and where you would also fetch some user data from Facebook and store that locally in the database.

If you have maybe three external providers (e.g. Twitter, G+, etc), you would receive three different tokens from them and you’d have to store all of these tokens in your user record on the server-side. This is to make sure you can actually identify the user when you have an incoming request for one of these tokens. However, you’d ideally want to have one authorization mechanism that’s used for all of the incoming requests. For example, you should send the Facebook token to your server as soon as you receive it, validate it, and then return a bearer token (which is the one and only token you use for identifying that user in API requests.) So the bearer token is more or less for streamlining your client-server interaction.

Role Authorization through Ember Simple Auth

There are two parts of Role management in Ember Simple Auth. First, you have the UI part where you don’t display certain things for the client side.

{{if session.isAuthenticated}}

In the templates – for example, if session is authenticated, then it is allowed to do something. Role management is about making sure that people are allowed to do something or not, and it has to happen on the server. If it’s on the client, you don’t have any actions going on to change the data. Also, you’d have no way of securely implementing something that makes sure that the user isn’t able to do something, especially since it’s all JavaScript and you can change it if you look into the code.

So, role management has to happen on server-side. If you just have the incoming request that contains the token, that’s enough information to check the server-side to make sure whether the users can or cannot do something.

Why Use Ember.js vs. AngularJS

I more or less had to build Simple Auth on top of Ember because I started using it at when was the framework was still in its early stage, so no authentication libraries existed for it.

However, I chose Ember instead of Backbone or Angular because I have been developing with Rails for about 8 years or so. If you look at Ember and you come from a Rails background, you’ll think it’s more or less the same thing. It just runs in the browser, but still it’s got very familiar concepts and structure.

So overall, as a Rails dev, getting into Ember was a very smooth transition. You’ll get all that enforced structure and clear ways of how to do things just like in Rails, so you’d really appreciate Ember.