Introduction to OAuth2 part 4: the implicit flow


We looked at the code flow of OAuth2 in the previous part of this series. We’ll continue by looking at the so-called implicit flow.

The implicit flow is mostly used for clients that run locally on a device, such as an app written for iOS or Windows 8. It is also applicable for packaged software that runs within a user agent on a client device. These act like local clients but they are not written as true native software.

We have to solve the same problem as before: the local application wants to access a protected resource on behalf of the resource owner who is not willing to provide the password. There are a lot of applications that use your data from Twitter, Facebook, LinkedIn, blog platforms etc. The majority of them do not originate from the respective companies but were written by third-party app developers. You as a Facebook user may not be happy to provide your password to those apps due to security concerns.

The solution is similar to what we saw in the case of the code flow: you won’t give your password to the native application but to the auth server. The client app will then retrieve an access token from the auth server which it can use to access the resource.

You’ll see that the implicit flow is really nothing else but a simplified version of the code flow.


First the app will need to contact the auth server of the service the client app is using as the authentication platform. You’ve probably seen options like “sign in with your facebook/google/twitter/etc. account” in some application on iPhone/Android/WindowsPhone. The application must be able to show the login page of the service. The GET request sent to the auth server looks very much like the one we saw previously:

GET /authorize?client_id=mygreatwindows8app&scope=resource&redirect_uri=

The only difference is response_type=token, the other elements should look familiar. The native application won’t get an access code from the auth server but the token directly. Remember that in the code flow the requesting page had to do some background task where it asked for the token using the code it got from the auth server. This extra step is missing here in the implicit flow.

The native app must be prepared for showing the login page of the auth server. Example: Azure Mobile Services allows a mobile app to register with Microsoft, Facebook, Google and Twitter. So if you write an application and want to let Azure handle the backend service and notifications for you then you can register your app with those services and you can offer your users to log in with the account they wish. The following is the top part of the Azure sign-up page – the full page is too long, but you get the idea:

OAuth signup page on Azure Mobile Services

The application will then need to show the correct login page and consent screen of the selected provider. Here’s an example for the Google login on iOS:

Google login on iOS

This login page can be either shown in a popup window or as an embedded screen within the app, that’s only an implementation detail.

If you give your consent to share your data with the app then the auth server will respond with a GET request to the callback. The request will contain the token details as query parameters in the URL. Example:

GET /redirect#access_token=some_code&expires_in=300&state=same_as_in_the_original_request

Note the ‘#’, it’s not a typo. We won’t use a callback ‘?’ but a callback hash in this case. The callback is hash fragment encoded. The idea with this is that the query parameters won’t be sent to any server, they will be hidden and won’t show up in the referrer URL. Everything after the hash is only meant for the immediate recipient, it won’t be propagated further on. Otherwise the token could leak to a third party.

The token is anyhow exposed to the native app and the browser where the login page is shown. The client app won’t authenticate with the auth server, unlike in the code flow, so usually refresh tokens are not an option. If the client app had to authenticate with the auth server then the client credentials would need to be stored on the device, which is not ideal from a security point of view. Keep in mind that the user won’t have full control over the application, so saving the full credentials locally is normally not a good idea.

The application can now request the protected resource using the token. Usually the token is put into the auth header of the request to the resource server as type ‘Bearer’:

Authorization: Bearer ‘the access token’

We said that refresh tokens are normally not provided in the standard way of implementing the flow. However, this doesn’t mean that there are no workarounds out there. E.g. Google uses a hidden iframe with a cookie to avoid showing the consent screen again and again. The lifetime of the cookie will then be longer than that of the token and the user will have to log in again after 2-3 weeks.

Read the next part in this series here.

You can view the list of posts on Security and Cryptography here.

About Andras Nemes
I'm a .NET/Java developer living and working in Stockholm, Sweden.

7 Responses to Introduction to OAuth2 part 4: the implicit flow

  1. Hi Andras,

    thanks for the article. Hopefully you can point me in the right direction concerning the next question. I am setting up an ASP.NET MVC Web application that will interact with a Web API (2.0) application. I need to setup authentication with an Identity Provider based on OAuth2 – implicit flow for this MVC app. I don’t want to do this on every request (the app is a private portal authentication must be checked on every request), so I think I want to store the JWT (token + claim) in a session cookie.
    I have read multiple articles on your website and I have an idea about the puzzle pieces but I am trying to put them together. Hopefully you can help me a bit.

    Kind Regards,

    • Andras Nemes says:

      Hi Bas,

      Just to verify that I understand the setup: is the MVC web app required to authenticate with the Web API 2 app? Is the identity provider some external application or is it also part of the Web API application?

      • Hi Andras,

        thanks for the quick response.

        The MVC app will use JQuery (ajax) calls to the Web API 2 app to do its CRUD operations, so yes. The Identity provider is an external application that (at the moment) only supports the implicit flow (code flow will be implementend within a couple of weeks).


      • Andras Nemes says:

        Hi Bas,

        OK, so the MVC app will get an auth token from the identity provider and will use that token to authenticate with the web api app, is that correct?

        You can send the token to the web api app in the HTTP header. As a web api application is normally session-less, I think you’ll need to include the token in every call to the web api to pass authentication.

        FYI: i’m going to publish a short intro into Web API 2 soon. The last (3rd) part of that intro deals with OAuth authentication using jQuery and bearer tokens. The setup is different from yours but you might take some ideas from there: in my example the Web API app will hold the user data in its repository.

  2. Hi Andras,

    you are right, the web API app needs the token voor authentication so the MVC app will need to get this from the IDP. How do I integrate this part in the MVC application? I saw some examples with custom providers in MVC. Is that the way to go? I also read something about OWIN Forms authentication.


    • Andras Nemes says:

      Hi Bas,

      You mean how you integrate the IDP in the MVC app? I’m not sure how much you’ve read on this blog but look through the posts on Claims. You’ll see an example there where I go through the integration of the Thinktecture identity server. As far as I know this IDP also supports OAuth2, but it’s better if you check with the authors of that project.

      When you ask an auth token from a Web API 2 app then it’s OWIN that takes care of that. Web API 2 and OWIN will be covered soon on this blog, you can check the schedule on the home page.

  3. Pingback: Web API 2 Excel File Export With OAuth2 Implicit Flow | Software Engineering

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.

%d bloggers like this: