Category: App

Categories
App Javascript

AngularJS vs Angular

Introduction

Probably, for most of front-end developers, Angular is a well known framework made for building web applications. If we want to use Angular in our project, we have to choose one of its versions – AngularJS or other. 
AngularJS – or as some may prefer: Angular 1 – was created in 2009. It brings us two?way data binding and lets us see data changes in JavaScript automatically shown on the UI. Furthermore, AngularJS has directives that let us create more separated and reusable code than ever before. Generally it allows us, programmers, to write applications in MVC or MVVM architecture (sometimes called MVW architecture (Model-View-Whatever) in simpler way. It made a step forward in testing front-end applications, because of its dependency injection mechanism which helps mock dependencies.

The beginning

I must say that I was really fascinated in Angular. Over time it has gained support from many developers. They’ve created a lot of useful packages that made coding even faster. More and more things were added to the core, so the Angular team decided to create a completely new framework. At first, the new framework was named Angular 2. It sometimes may cause understatements, because after time, beta version was renamed to Angular. Now, when people want to find some pieces of AngularJS code, they may find stuff connected with Angular 2 or higher. Higher, because Angular 4 was announced on December 2016. Creators purposely skipped number 3 to avoid a confusion due to the misalignment of the router package’s version, which was already distributed. Angular in 4th version is backward compatible with Angular 2.

Controllers vs components

So what’s the difference between AngularJS and Angular? First of all, Angular is based on TypeScript while AngularJS is based on JavaScript. TypeScript is a superset of ES6 and it’s backward compatible with ES5. Angular has also benefits of ES6 like: lambda operators, iterators or reflection’s mechanism. 
AngularJS uses terms of scope and controller. To scope a variable you can add many variables that will be visible in View as well as in Controller. AngularJS has also a concept of rootScope. Variables in rootScope are available on all throughout application. Angular does not have a concept of scope or controllers. Instead of them it uses a hierarchy of components as its main architectural concept. Component is a directive with a template. That is a similar approach as in ReactJS – another library used for building user interfaces.

Differences in template engine

AngularJS has many directives and every developer can also specify custom new directive. Angular also has standard directives, but they are used in a bit different way. For example: ng-model in AngularJS means that you want to create two-way binding. If you want to create one-way binding, you should use ng-bind. Angular occurs only ngModel, but if you would write it only in: “[ ]”, you’ll get one-way binding. If you want to create two-way binding you must write it in: “[( )]”. We have to write it this way because of the fact that “[ ]” is used to property binding and “( )” is used to event binding. In Angular, some directives have changed their names like ng-repeat to ngFor. When I’ve started working on projects with Angular 2 in beta version, I’ve been making common mistakes at the beginning liken trying to use ng-repeat or ngModel only in square brackets when I wanted two-way binding.

What else have changed?

Of course if Angular is newer version you can suspect that has some advantages over the old version. That’s right, Angular has many advantages. The first is modularity. Much core functionality was moved to different modules. That caused lighter and faster core, dynamic loading, asynchronous template compilation and added support for reactive programming. After beta version creators added really great thing: angular cli. With that package you can easily create scaffolding of your Angular project which will be all configured.

So AngularJS or Angular?

Wondering about version that will be the best for you? The newer version of Angular is a popular solution. Moreover, mostly it will be a better choice. Anyway, before you choose one of them to your new project, try to answer some questions: 
What libraries would you like to use? 
Are they compatible with Angular? 
What web browsers we want to support? (this one is really important)
If you choose only new browsers, then Angular is the best. It’s because it is a forward-looking library, but don’t forget about other browsers. For example: IE8 for which you should definitely use AngularJS from version 1.3 that supports IE8 and higher.

Summary

Angular is a great framework. It has many improvements in terms of AngularJS. It will become more and more popular and I think that it is well suited to small as also to bigger applications, so it is really worth learning and using.

'Coz sharing is caring
Categories
App HTTP Concepts Technology Web Trends

WS-Fed vs. SAML vs. OAuth vs. OpenID Connect

Identity protocols are more pervasive than ever. Almost every enterprise you would come across will have an identity product incubated, tied with a specific identity protocol. While the initial idea behind these protocols was to help enterprise employees use a single set of credentials across applications, but new use cases have shown up since then. In this post, I am going to provide a quick overview of major protocols and the use cases they are trying to solve. Hope you will find it useful.

WS-Fed & SAML are the old boys in the market. Appearing in the early 2000s they are widespread today. Almost every major SSO COTS product supports one of these protocols. WS-Fed (WS-Federation) is a protocol from WS-* family primarily supported by IBM & Microsoft, while SAML (Security Assertion Markup Language) adopted by Computer Associates, Ping Identity and others for their SSO products. The premise with both WS-Fed and SAML is similar – decouple the applications (relying party/service provider) from an identity provider. This decoupling allows multiple applications to use a single identity provider with a predefined protocol, and not care about the implementation details of identity provider per se.

For web applications, this works via a set of browser redirects and message exchanges. User tries to access the web application, the application redirects the user to the identity provider. A user authenticates himself, identity provider issues a claims token and redirects the user back to the application. The application then validates the token (trust needs to established out of band between application and IdP), authorizes user access by asserting claims, and allows the user to access protected resources. The token is then stored in the session cookie of user browser, ensuring the process doesn’t have to be repeated for every access request.

At a high level, there isn’t much separating the flow of these two protocols, but they are different specifications with each having its own lingo. WS-Fed is perceived to be less complex and light weight (certainly an exception for WS-* family), but SAML being more complex is also perceived to be more secure. At the end you have to look at your ecosystem including existing investments, partners, in house expertise, etc. and determine which one will provide higher value. The diagram below taken from wiki depicts the SAML flow.

OAuth (Open Standard for Authorization) has different intent (the current version is OAuth 2.0). It’s driving force isn’t SSO but access delegation (the type of authorization). In simplest terms, it means giving your access to someone you trust, so that they can perform the job on your behalf. E.g. updating status across Facebook, Twitter, Instagram, etc. with a single click. The option you have is either to go to these sites manually or delegate your access to an app which can implicitly connect to these platforms to update status on your behalf. Flow is pretty simple, you ask application to update your status on Facebook, app redirects you to Facebook, you authenticate yourself to Facebook, Facebook throws up a consent page stating you are about to give this app right to update status on your behalf, you agree, the app gets an opaque access token from Facebook, app caches that access token, send the status update with access token to facebook, facebook validates the access token (easy in this case as the token was issued by Facebook itself), and updates your status.

OAuth refers to the parties involved as Client, Resource Owner (end-user), Resource Server, and Authorization Server. Mapping these to our Facebook example, Client is the application trying to do work on your behalf. Resource owner is you (you owe the Facebook account), Resource Server is the Facebook (holding your account), and Authorization Server is also Facebook (in our case Facebook issues the access token using which client can update status on Facebook account). It perfectly ok for Resource Server and Authorization Server to be managed by separate entities, it just means more work to establish common ground for protocols and token formats. Below screenshot depicts the OAuth2 protocol flow

Web community liked the lightweight approach of OAuth. And hence, the question came – can OAuth do authentication as well, providing an alternative to heavy lifting protocol WS-Fed and SAML? Enter OpenID Connect is about adding Authentication to OAuth. It aims at making Authorization Server do more – i.e. not only issuing access token, but also an ID token. ID token is a JWT (JSON Web Token) containing information about authentication event, like when it did it occur, etc. and also about the subject / user (specification talks of a UserInfo Endpoint to obtain user details). Going back to the Facebook example, here the client not only relies on Facebook to provide us an opaque access token for status updates, but also an ID token which client can consume and validate that the user actually authenticated with Facebook. It can also fetch additional user details it needs via Facebook’s UserInfo Endpoint. Below diagram from OpenID connect spec indicates the protocol flow.

OP in the above case is OpenID Provider. All OpenID Providers have the discovery details published via JSON document found by concatenating provider URL with /.well-known/openid-configuration. This document has all the provider details including Authorization, Token and UserInfo Endpoints. Let’s see a quick example with a Microsoft offering called Azure Active Directory (Azure AD). Azure AD being an OpenID Provider, will have the openid configuration for its tenant demoad2.onmicrosoft.com available at https://login.microsoftonline.com/demoad2.onmicrosoft.com/.well-known/openid-configuration.

'Coz sharing is caring