I am going to retire the current stack of technologies used in this blog in favor of more recent technologies, mainly because I currently author this blog using Windows Live Writer which is outdated and has lost the love of community. I am also taking this opportunity to create a new technology stack that is much more modular and allows me to focus only on writing. I am also learning cool new stuff which might be useful to all of us. I am super happy with a few components that I currently use and I would be reusing the things that are working well. The entire source code of this blog is available in my GitHub repository from where you can happily copy and paste stuff. You can also read about how I built the existing blog framework (v1) here. Of course, I would write about how I chose components for my new blogging platform and how you can set one up yourself, so stay tuned (even better, subscribe).

September 8, 2016: This activity is now complete and you are reading this post on my new blogging platform.

Azure Access Control Service is dead (well almost). Azure AD B2C is out, up and running and supports many of the common social accounts and even using new credentials. Both the Azure AD and Azure AD B2C use OAuth 2.0 mechanism to authorize access to resources of users. At this point some of you may want to understand…

What is OAuth 2.0?

If you like reading loads of text, here is what Microsoft’s documentation recommends that you read. For the rest of us, including me, we will use OAuth 2.0 playground to understand what OAuth is. For this activity you will require an account with Google and an interest in YouTube. We will use OAuth based flow to fetch the content that is displayed on your YouTube homepage.

There are four parties in the OAuth flow, namely:

1. Resource Owner: In our experiment this is you. The Resource Owner or user grants permission to an application to access his\her content (YouTube feed data). The access of application is limited to the scope of authorization (e.g. read only, write only, read-write etc.)
2. Authorization Server: This server stores the identity information of the Resource Owner, which in our case is Google’s identity server. It accepts user credentials and passes two tokens to the application.
3. Access Token: The token which the application can use to access the Resource Owner’s content.
4. Refresh Token: The token that the application can use to get a fresh Access Token before or when the Access Token expires. The Refresh Token may have a lifetime after which it becomes invalid. Once that happens, the user would be required to authenticate himself\herself again.
5. Client/Application: The Client is the application that wants to access the Resource Owner’s data. Before it may do so, it must be authorized by the Resource Owner and the authorization must be validated by the Authorization Server.
6. Resource Server: This the application that trusts the Authorization Server and will honor requests that are sent with Access Tokens by the application. This in our case is YouTube. Resource Owner can limit the authorization granted to the client by specifying the Scope. You must have seen the application of Scope in Facebook’s ability for users to authorize a variety of different functions to the client (“access basic information”, “post on wall”, etc.).

#azure ad b2c #azure ad