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 available at

'Coz sharing is caring

How To Get Multiple Facebook Like Buttons

In this article, I will attempt to be as clear as possible. Again, my technical expertise may not be up to par with, say, Mark Zuckerberg, but I will do my very best to keep the terminology and code as accurate as possible.

First Things, First:
Getting The Facebook Like Button

Before you get the code for a Facebook Like button from developers.facebook, I recommend you set up your website as a Facebook application. This will give you valuable tools to manage your Facebook plugins (such as analytics tools, which allows you to see how users are interacting with your buttons, and moderating tools for the comment box (which, by the way, you can get the code for here)

Setting up your website as a Facebook application can seem a little daunting. I found this article and it walked me through step by step through the entire process. Tutorial: How to Create a Facebook Application to Get an App ID for your Website or Blog.
I recommend you get the code for the Like button AFTER you set up your site as a Facebook application.

Place Facebook Like Button Code On Your Website

I didn’t want to glaze over this part, just in case.When you retrieve your Facebook like button code from the developers.facebook button generator, you will get two codes:

The code in the first box is the main Facebook plugin code that applies to ALL Facebook plugins on that particular page (including comment box, etc). This code will go right after the opening < body > tag of your page. You only need this code once per page regardless of how many like buttons or other comment boxes you have on that particular page.

The code in the second box, is the code to display the actual like button.This is the code you will post wherever you want your like button to appear.

Notice that there are some elements that need customizing:On the first box, fifth line:

js.src = \"//";

If you generated the button code after your made your website a facebook object (Tutorial: How to Create a Facebook Application to Get an App ID for your Website or Blog), facebook will automatically insert your website’s id here and so that line will read:

js.src = \"//";

But, if you didn’t, then you will need to enter this manually (that is, if you got an ID in the first place).

Also, on the second box, the url will be customized. You can leave that as anything for now, I will show you below what this URL should be in order for each like button to reference different items.

Meta Tags

Now that you have your website set up as a Facebook application, and you’ve generated a like button from the developers.facebook page, let me show you how to place it in your code.
The first thing you have to know is that the code you generated from the facebook like button doesn’t have the meta tags included.meta tags are a set of instructions for the browser, they go in between the < head > tags. Facebook plugins use meta tags to figure out what information to display on Facebook when someone Likes or Comments on your post. The meta tags we will be working with look like this:

< head >
< meta property="fb:app_id" content="YOUR-APP-ID"/>
< meta property="fb:admins" content="USER_ID,USER_ID"/ >
< meta property="og:title" content="Page Title"/>
< meta property="og:type" content="object Type"/>
< meta property="og:site_name" content="The Name You want to display as the main webpage"/ >
< meta property="og:url" content=""/>
< meta property="og:image" content="http://URL-TO-IMAGE"/>
< meta property="og:description" content="Description of page content"/>
< /head>

fb:app_id is the id# given to you by facebook when you created an website object.
fb:admins is the facebook user id of whoever you wish to be able to be a moderator of your facebook plugins (you can enter multiple ids, separated by commas). This id is usually in the url of your facebook homepage.
og:title is the title that displays on facebook when button is clicked.
og:type Facebook has a predefine list of object types that can be found here But you can go with “website”
og:site_name this is the website title (not article title) that will display when someone clicks the link (ie. your website name).
og:url this is the url of the current page
og:img the url of the image facebook will display
og:description the description facebook will display

Here’s why multiple like buttons on one page becomes tricky: Each html or php page can only have one of each Meta Tag. Meaning, when you define:

<meta property="og:title" content="Title To Display "/ >

Every like button on the page will reference that title. The same with the rest of the tags. And while some of the tags do, indeed, remain the same regardless of the content (such as the fb:app_id, fb:admins, og:site_name) others (like og:title, og:image, og:url, and og:description), should be specific to what the link is referring to.

The solution is simple: every like button needs a separate set of meta tags.
The execution is also, surprisingly simple: every like button needs to reference a separate html or php document that contains the content specific meta tags.

Multiple Like Buttons For Different Items

Step 1: Modify your HTML tags so that it doesn’t interfere with the Facebook meta tags:So, instead of < html > < /html > , use

< html xmlns:og="" >
< /html >

Step 2:Your main page (the page that contains the multiple like buttons) can contain the meta tags for the main article, or general metatags for the website. Otherwise, the like button you want to display the information displayed in these meta tags will need to contain the url of the page.

Step 3: For EACH article/item that you want a like button for, create a separate html or php page (unless the article already has a separate page– in that case, place the content specific meta tags on that page.).On that HTML or PHP page, you will need to include the meta tags in between the < head > < /head > tags.

So the HTML it should look something like this:

< html xmlns:og="" >
< head >
< title > This is your Standard Page Title < /title >
< meta property="fb:app_id" content="YOUR-APP-ID"/>
< meta property="fb:admins" content="USER_ID,USER_ID"/ >
< meta property="og:title" content="Page Title"/>
< meta property="og:type" content="website"/>
< meta property="og:site_name" content="The Name You want to display as the main webpage"/ >
< meta property="og:url" content=""/>
< meta property="og:image" content="http://URL-TO-IMAGE"/>
< meta property="og:description" content="Description of page content"/>
< /head >
< body >
< /body >
< /html >

(include doctype, if needed, before the html start tag)

Step 4: Now that you have an HTML or PHP page with content unique meta tags in the head, you will need to edit the code of EACH like button so that it references the page that contains it’s meta tags.
The code for the individual Like buttons looks like this (may vary depending on the style you chose from the facebook button generator, just focus on the href tag information):

The url within this href tag MUST match the url in the meta tag og:url otherwise, the like button wont reference the correct information. Remember, the url in the meta tag og:url is the url of the html or php page that contains the meta tag.

< fb:like href="full URL of page that contains the meta tags related to THIS like button" layout="button_count" show_faces="false" width="240" height="40" action="like" colorscheme="light" >

Also, don’t forget the Facebook plugin script (the code in the first box that is generated when you make a button) that goes right under the opening body tags of each page that has like buttons (again, just one is needed per page).

One thing I want to mention, because like I said I spent hours gnawing my eyes out over this. First, code one or two like buttons at a time and double, triple check your code. One tiny error can cause the entire plugin to not work properly. If you code a crap load of like buttons at once and you have an error, it will likely take forever to go through each one and fix them individually. So perfect your code, then copy and paste and customize.

Thankfully, Facebook developers created a debugger that will let you know what Facebook can see from your link. Basically, you enter the url of the site you want to check (in your case, the URL with the meta tags of the like button you want to test) and the debugger will let you know if there are any errors. Listen to it. I didn’t, for a while. I kept thinking, this is obviously wrong because I can’t find the error it’s pointing to. But nope, it ended up being right and I wasted time resisting technology that is far smarted than I.

'Coz sharing is caring