Skip to main content

How to simulate token expiration if an user is idle on an AngulaJS using Bearer Token (OWIN and Katana)

In one of the project where I was involved I used token based authentication to secure a REST API endpoint -  bearer token. The setup was pretty simple, using OWIN and Katana on backend and AngularJS on the client side.
There is a great sample on GitHub, that can be used for learning purposes - https://github.com/tjoudeh/AngularJSAuthentication
This days a new requirement came from the client. The authentication session should expire if there is more than 30 minutes with no activity from client. By default when a token is issued it is available for a specific time interval. The value can be specified as below:
OAuthAuthorizationServerOptions oAuthServerOptions = new OAuthAuthorizationServerOptions
{
AllowInsecureHttp = false,
TokenEndpointPath = new PathString("/token"),
AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(30),
Provider = new SimpleAuthorizationServerProvider(),
AuthenticationMode = AuthenticationMode.Active
};
This will works great in normal scenarios, but in our cases we had some problems.

The token is valid from the moment when is created for a specific time interval, in our case 30 minutes. Even if the user access the services using the token in minute 29, the token will expire and he will need to request a new token or to authenticate again entering his user and password.
An option is to use refresh token and track the last access time in a storage (cache, session or a database). The problems with this solution is:
-          We don’t have a cache yet
-          We don’t use session because we don’t need it
-          A solution with a DB would require an implementation effort and we need to see what is the impact over current DB

Before jumping to the solution that we thought, you should know that on the server there are no information that are stored related to token or user. The token is encrypted using machine key and can used only by the machine or machines that have the same machine key. The bearer token contains all the information related to user, from user ID to claims (current roles or actions that he can do on the server). Don’t forget that we cannot invalidate a bearer token because the server don’t track or store any kind of information related to it.

Based on the above information we measured how long it takes to generate a new bearer token on the server and the performance impact was minimal – with almost no additional resources.

Our solution:
  • On the ActionExecuted of an action filter generate a new bearer token after each call for authenticated users
  • Send this token to the client application
  • Persist this token on the client application
  • Use the token at the next call

The con of this solution is that we generate a new token at each call.
Below you can find the ActionFilter that generate a new token after each call using the claims from the previous call.
public class InjectNewTokenActionFilter : ActionFilterAttribute
{
    public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
    {
        base.OnActionExecuted(actionExecutedContext);

        ClaimsPrincipal principal = GetCurrentPrincipal(actionExecutedContext.ActionContext);
        if (principal == null)
        {
            return;
        }
        var newToken = CreateAuthTicket(principal);

        string token = Startup.OAuthBearerOptions.AccessTokenFormat.Protect(newToken);
        actionExecutedContext.Response.Content.Headers.Add("NewToken", token);            
    }

    private ClaimsPrincipal GetCurrentPrincipal(HttpActionContext actionContext)
    {
        ClaimsPrincipal principal = actionContext.RequestContext.Principal as ClaimsPrincipal;
        return principal;
    }

    private AuthenticationTicket CreateAuthTicket(ClaimsPrincipal oldPrincipal)
    {
        ClaimsIdentity identity = (ClaimsIdentity)oldPrincipal.Identity;
        AuthenticationProperties props = CreateAuthenticationProperties();
        AuthenticationTicket ticket = new AuthenticationTicket(identity, props);
        return ticket;
    }

    private static AuthenticationProperties CreateAuthenticationProperties()
    {
        AuthenticationProperties props = new AuthenticationProperties(new Dictionary<string, string>
        {
            {
                "client_id", string.Empty
            }
        });
        return props;
    }
}
And the JavaScript code that can be used on client side to update the bearer token for each response. This was done by intercept the http response.
var Services = Services || {};
Services.authInterceptorService = function ($q, $injector, $location) {
    ...
    var response = function(response) {
        //Sample
        IF(heather new token is set)
{
       SET NEW VALUE TO globalObjWhereTokenisStored.token = header(‘NewToken’)
}

        return response;
    }

authInterceptorServiceFactory.response = response;

    return authInterceptorServiceFactory;
};

Comments

Popular posts from this blog

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Why Database Modernization Matters for AI

  When companies transition to the cloud, they typically begin with applications and virtual machines, which is often the easier part of the process. The actual complexity arises later when databases are moved. To save time and effort, cloud adoption is more of a cloud migration in an IaaS manner, fulfilling current, but not future needs. Even organisations that are already in the cloud find that their databases, although “migrated,” are not genuinely modernised. This disparity becomes particularly evident when they begin to explore AI technologies. Understanding Modernisation Beyond Migration Database modernisation is distinct from merely relocating an outdated database to Azure. It's about making your data layer ready for future needs, like automation, real-time analytics, and AI capabilities. AI needs high throughput, which can be achieved using native DB cloud capabilities. When your database runs in a traditional setup (even hosted in the cloud), in that case, you will enc...

Azure Service Bus - How to extend the lock of a message | RenewLock

In this post we will discuss about Azure Service Bus Topics and Queues, with a special focus on Peek and Lock feature. Introduction Azure Service Bus is a messaging system that allows us to send messages between different systems in a reliable and easy way. A lot of concepts from ESB are implemented by Service Bus, allowing us to do do magic stuff with messages. There are two ways to consume messages from Service Bus Peek and Lock - locks a message for a specific time internal and notify Service Bus when we want to mark the message as processed (removed from Service Bus) Receive and Delete  - once a message is received from Service Bus, it is also deleted automatically from the messaging system Peek and Lock When using Peek and Lock, by default we lock the message for 60 seconds. This means that in this time interval the message is not available/visible for other consumers. Once we process the message we can mark it as processed. If we don't mark the message as processe...