Token based implementation in webapi to secure endpoints

Question

I am having a web application with web service and client will register their application using my web application.

Now client will have application of type SPA or mobile apps and they will consume my webservices from their apps.

So I would be implementing token based mechanism for securing access to my endpoints.

1) But here I am confused that shall I use any framework to generate access token or I can use any library which will generate any random string which i will send in response.for instance something like this :

TokenId = Convert.ToBase64String(Guid.NewGuid().ToByteArray()).Replace("+", "_")

So while registering application if client have enabled authentication for their application then user will be validated and then I will return access token and also save accesstoken in my database with that user id.

So my database table would be like below for storing validated accesstoken :

Id(autogenerated)   accesstoken    userid   clientid    createdat    expiresat

So after user is authenticated and now if user want to access any protected resources then user need to pass this access token in subsequent call in header.

So what I will do I will get access token from header and then validate that accesstoken against that database and then allow access to my protected resource other wise user would get authorized.

I have seen lots of things related to this so basically this is oauth2 and I want to implement this.

I have seen Openid connect(this project doesnt even compile) which is on top of oauth2 and which is used for authentication and oauth2 will be used for authorization.

But here as I am storing access token in my database so here is my doubt related to that :

2) Now do I need openconnectid (but this project doesn't even compile) for validating access token or as I am having storing access token in my database I don't need openconnectid?

3) I want to implement asp.net identity but then I will receive dynamic database connection string and as i have seen asp.net identity mostly works with entity framework I couldn't find any source where I could use ado.net to validate username and password using SQL query. I know I can do something like this :

Make a custom user class which implements IUser as described here Define a custom user store which implements

public class UserStoreService 
     : IUserStore<CustomUser>, IUserPasswordStore<CustomUser>

But I won't be having this information as I don't have fixed connection string.connection string again is stored in database with client registration.

4) We have given user a fixed endpoint through which client can create an admin so for that I will use my RSA algorithm for password hashing and then store it in database. So with this now do i need to use asp.net identity?

5) I have seen lots of following link with token based implementation but I am not getting where they are validating accesstoken in which part but now as I am having accesstoken stored in my database do I need to use any of the following implementation?

http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/

http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/

6) Moreover if for any client if client don't want authentication for its respective application then what I will do is I will don't have that username password validation but I will simply generate accesstoken and then send in response so then in every subsequent request that access token will be pass to access protected resources.Do you think this make sense?

I have never seen any example where access token is store in database and problem with storing access token in database would be I have to make a call to database every time to validate access token for each endpoint.

Update :

Use case of my webservice engine would be:

1) Support multiple client application.

2) Manage user session in the form of token management for each client application. So here as most of the article is storing accesstoken in identity and that identity is validated inside [Authorize] attribute in which accesstoken is also validated and based on that user is allowed to access protected resources.This is what my understanding is up until now.

So if I also user identity and store user context inside identity supporting multiple client application is a good idea?

Gomer

Hi Learning. I wondered here and here whether you would try to make some effort to observe case and apostrophe rules for your writing, and here I am having fixed another 30 or so errors in your post. Your English is clearly fine, so I am left wondering whether you are composing your posts on a mobile phone, or are these errors stylistic, and thus deliberate? Remember Stack Overflow is not a forum - it's a Q&A site, where we try to maintain at least some standards for clarity. – Scornful

There are a number of volunteer editors who are willing to help adjust and improve posts, but we are not your auto-correct. Can you please help? – Scornful

I have posted this question from computer so sometimes i do miss apostrophe and some other errors(i guess) but i think my purpose of question is easily understandable and clear but still i am sorry if i have made mistake anywhere. – Gomer

If you like, you can see the repairs made in the question's revision history - I counted 37 fixes - it isn't just one or two. By your response, do you mean that you would like volunteers to repair your mistakes in every post you make in the future? – Scornful

No sorry i didnt mean that but i dont see any need to improve those things in my question unless and untill it is making sense to reader of question :) – Gomer

Well, you have now learned that the community does care about these things, and you can ask a Meta question about it if you wish to. If you post, let me know, so I can respond as well. Note that when you make errors in your posts, editors generally will fix them, so if you do so knowingly, you are wasting someone's valuable time deliberately. It should go without saying that this is not very kind. – Scornful

Answer 1

From “7.1. Access Token Representation” in “Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings” :

How should an access token be represented? There are two major ways.

1. As a meaningless random string. Information associated with an access token is stored in a database table behind an authorization server.

2. As a self-contained string which is a result of encoding access token information by base64url or something similar.

Pros and cons of these two ways are described in the blog.

If access tokens are random strings, pieces of information associated with the access tokens (user ID, client ID, scopes, lifetime, etc.) are stored in a database which is managed by the authorization server which have issued the access tokens.

Whenever a resource server which exposes APIs accepts an API call from a client application, the resource server has to get the information about the access token in some way or other.

If the resource server can access the database managed by the authorization server (in other words, if the resource server and the authorization server shares the database), the resource server can get the information about the access token from the database directly.

Otherwise, the resource server has to make an API call to the authorization server to get the information. In this case, it can be expected that the authorization server exposes an API which complies with RFC 7662 (OAuth 2.0 Token Introspection). Note that some implementations may provide a more developer-friendly API than RFC 7662 (e.g. “4. Introspection Access Token”).

Anyway, your resource server doesn't necessarily have to make a DB call (or an introspection API call to the authorization server) every time if the server caches information about access tokens in a memory cache or somewhere else appropriate.

BTW, what you need when you want to protect APIs is access tokens. Therefore, your system doesn't have to support OpenID Connect which is a specification as to how to request and issue ID tokens. You may be confused because a server which supports OpenID Connect can issue access tokens, too, in addition to ID tokens. See “Diagrams of All The OpenID Connect Flows” to understand what a server which supports OpenID Connect issues.

Finally, identity management, user authentication, and OAuth 2.0 & OpenID Connect don't necessarily have to be implemented in a monolithic way. See “New Architecture of OAuth 2.0 and OpenID Connect Implementation” for details.

Vereen

Upvoted for your kind efforts towards helping me and thank you so much.I am trying to follow this link(bitoftech.net/2014/06/01/…) basically what i understand is that and what i have seen up till now is like when user is validated then user identity is created like context.user which contains information about user if i am not wrong and then accesstoken is generated.But the only confusing thing is how accesstoken information is put inside context and validated by resource server for allowing access to protected resource? – Gomer

There are various ways to implement identity management, user authentication, and OAuth 2.0 & OpenID Connect. The article you are referring to is just one out of various implementations. IMHO, access token information should not be put in the user context, but the solution in the article you are referring to may put both user information and access token information into one place (user context), but I'm not sure. – Vereen

I have added use case in my question.Can you please tell me something about that your views – Gomer

Answer 2

No, you don't need to store the access_token on the database. You can decrypt the JWT and read the information as you are the one who encrypts it with a secret key. (By default it's the machine key.)

Identity has a off the self support for Oauth. You have to just configure it properly. You can set-up the configuration for OAuthAuthorizationServerOptions in the Startup.Auth.cs. Sample code as follows. I have tried to answer most of your question in comments in the code.

public static OAuthAuthorizationServerOptions OAuthOptions { get; private set; }

    public static string PublicClientId { get; private set; }

    public void ConfigureOAuth(IAppBuilder app)
    {
        // Configure the application for OAuth based flow
        PublicClientId = "theDragonIsAlive";
        OAuthOptions = new OAuthAuthorizationServerOptions
        {
            TokenEndpointPath = new PathString("/Token"),
            Provider = new YourOwnApplicationOAuthProvider(PublicClientId),
            //AuthorizeEndpointPath = new PathString("/Access/Account"),
            AccessTokenExpireTimeSpan = TimeSpan.FromDays(7)
            //AllowInsecureHttp = true
        };

        // Enable the application to use bearer tokens to authenticate users
        app.UseOAuthBearerTokens(OAuthOptions);

    }

public class ApplicationOAuthProvider : OAuthAuthorizationServerProvider
{
    private readonly string _publicClientId;

    public ApplicationOAuthProvider(string publicClientId)
    {
        if (publicClientId == null)
        {
            throw new ArgumentNullException("publicClientId");
        }

        _publicClientId = publicClientId;
    }

    public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
    {
        var userManager = context.OwinContext.GetUserManager<ApplicationUserManager>();
        // This where you are validating the username and password credentials.
        ApplicationUser user = await userManager.FindAsync(context.UserName, context.Password);

        if (user == null)
        {
            context.SetError("Dragon Fire:", "The user name or password is incorrect. You shall be burnt.");
            return;
        }

        ClaimsIdentity oAuthIdentity = await user.GenerateUserIdentityAsync(userManager,
           OAuthDefaults.AuthenticationType);

        AuthenticationProperties properties = CreateProperties(user.UserName);
        AuthenticationTicket ticket = new AuthenticationTicket(oAuthIdentity, properties);
        context.Validated(ticket);
        context.Request.Context.Authentication.SignIn(oAuthIdentity);
    }

    public override Task TokenEndpoint(OAuthTokenEndpointContext context)
    {
        foreach (KeyValuePair<string, string> property in context.Properties.Dictionary)
        {
            context.AdditionalResponseParameters.Add(property.Key, property.Value);
        }

        return Task.FromResult<object>(null);
    }

    // This method is where you will create the client access token.
    // First you get the client, you can place values from the client record into the tokens claim collection.
    // You then create a new ClaimsIdentity.
    // You add some claims, in the example client name is added.
    // Create an AuthenticationTicket using your claims identity.
    // Validate the ticket (you do need to do this or the client will be considered unauthenticated)
    //public override Task GrantClientCredentials(OAuthGrantClientCredentialsContext context)
    //{
    //    var client = clientService.GetClient(context.ClientId);
    //    var oAuthIdentity = new ClaimsIdentity(context.Options.AuthenticationType);
    //    oAuthIdentity.AddClaim(new Claim(ClaimTypes.Name, client.ClientName));
    //    var ticket = new AuthenticationTicket(oAuthIdentity, new AuthenticationProperties());
    //    context.Validated(ticket);
    //    return base.GrantClientCredentials(context);
    //}

    // This method has to be implmented when you are maintaining a list of clients which you will allow.
    // This method is for validating the input, you can used this method to verify the client id and secret are valid.
    public override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
    {
        //string clientId;
        //string clientSecret;
        //context.TryGetFormCredentials(out clientId, out clientSecret);

        //if (clientId == "1234" && clientSecret == "12345")
        //{
        //    context.Validated(clientId);
        //}

        //return base.ValidateClientAuthentication(context);

        // Resource owner password credentials does not provide a client ID.
        if (context.ClientId == null)
        {
            context.Validated();
        }

        return Task.FromResult<object>(null);
    }

    public override Task ValidateClientRedirectUri(OAuthValidateClientRedirectUriContext context)
    {
        if (context.ClientId == _publicClientId)
        {
            Uri expectedRootUri = new Uri(context.Request.Uri, "/");

            if (expectedRootUri.AbsoluteUri == context.RedirectUri)
            {
                context.Validated();
            }
        }

        return Task.FromResult<object>(null);
    }

    public static AuthenticationProperties CreateProperties(string userName)
    {
        IDictionary<string, string> data = new Dictionary<string, string>
        {
            { "userName", userName }
        };
        return new AuthenticationProperties(data);
    }
}

The sample code above does not have separate client classifications. It will treat all users as a single type of client. But I have given some example code in the comments which will guide you to get started in the right direction.

Disclaimer: I am not an expert on this(yet) and my setup is different. I had an existing MVC application with Owin and I had to build a webapi on top of it. This was my prototype code and it did the job. You will have to improve in it for your production code. Have fun and good luck.

Bromleigh

Upvoted for your kind efforts towards helping me.What if i want to skip ValidateClientRedirectUri that is i dont want to give redirect uri and hence want to skip this validation.is it possible? – Gomer

when we process the authorize endpoints, registered "client_id" and "redirect_uri" has to be validated before calling context.validated. If you don't validate the redirect_uri your application is susceptible to phishing attack. According to MSDN documentation, it says that, "The application MUST implement this call." Any reasons you don't want to do it? – Bromleigh

So are you saying that in case of implicit grant type where user is just passing clientid there should be registered redirecturi ? – Gomer

Yes. The redirect URI is the callback entry point of the app. After you validate the client, where should the client go? That is defined by the redirect uri. – Bromleigh

But cant i just return accesstoken in response and then after getting response client can configure in his javascript code where to redirect.wont this make sense? – Gomer

Yes. I think that is possible. But the usual use case is redirection. Think of the Facebook/Google Authentications, i.e. when you use the Sign in via Google/Facebook. The website/app directs you to Google/Facebook API and then Google/Facebook directs you back. In your case, they wont be redirected back. – Bromleigh