Tag Archives: web-api

Override the Default Login to provide Customized Identities in Windows Azure Mobile Services

It is very easy to override the default login feature (accessible by /login/[provider] endpoints) of the Windows Azure Mobile Services and customize it according to the need of your app. In this blog post, I am going to discuss how to do that, in particular, we want to be able to do the following:

  1. Add custom claims to the identity (the ability to provide authorization after authentication). In this example, we will add custom claims to the facebook identity.
  2. Add a new oAuth identity provider (in addition to the ones supported by the Windows Azure Mobile Services). In this example, we will add Foursquare as the new identity provider.
  3. Add a simple classical identity provider (login by username and password).
  4. Add support for multiple apps using the same backend. It is necessary, if you have a public API exposed and other people are making apps using your backend.

In this post, I am going to use the oAuth flow described in my previous blog post, which is:

  1. the app verifies the identity of the user elsewhere, i.e., native facebook app, and acquire an access_token,
  2. this access_token is used to login to Windows Azure Mobile Services.

But, the examples are easily extendable to any standard oAuth flow.

Continue reading

oAuth Flow for Mobile Apps with An External Identity Server

It is very common for mobile apps to depend on external login (like Facebook). In this article, we are going to discuss the oAuth flow for the following scenario:

  1. The user’s identity is verified by an external server, i.e., external authentication.
  2. The user’s access to a protected resource, i.e., an API endpoint, is determined by the internal server, i.e., internal authorization. In other words, the resource server and the authorization server in the oAuth 2.0 specification is the same server.

First, I will discuss the process and then I will give an example.

The oAuth Flow for the above scenario:

  1. The client, i.e., the mobile app, calls the external identity server and verifies the users identity. On a successful verification, it receives an token from the identity server. We will call it authorization_grant.
  2. The client sends the authorization_grant to the internal authorization server. The authorization server has a trust relationship with the identity server. So, it sends the authorization_grant to the identity server. If the identity server cannot verify the authorization_grant, it sends back 401 unauthorized to the authorization server, which it propagates to the client. If, however, the identity server successfully verifies the authorization_grant, then it sends back the user info to the authorization server. The authorization server checks the permissions of the user (by querying the database database or some other methods) and generates a token. We will call it the access_token. A typical access_token contains the user’s identity, permissions, and an expiry time. The authorization server sends back this access_token to the client.
  3. The client embed this access_token with each request for the protected resource, i.e., calling API endpoint. Depending on if the user is allowed to access the resource, he either gets it or receives 401 unauthorized.

Continue reading

Building your own API and Securing it with oAuth 2.0 in ASP.NET WebAPI 2

Objectives:

  1. Make a true RESTful Web API (enable CRUD functions by HTTP POST, GET, PUT, and DELETE).
  2. Enable Cross-Origin Resource Sharing, i.e., CORS (the accessibility of the API by JavaScript can be controlled).
  3. Enable Secure Authorization for API calls (use the OAuth 2.0 authorization framework).
  4. Enable Transport Layer Security, i.e., SSL (reject every non-HTTPS request).

Continue reading

Follow

Get every new post delivered to your Inbox.