Authentication Support in PortableRest 2.6

[robertmclaws]

So PortableRest is at the point where it is lightweight and stable, and handles basic scenarios very well. It's time to start adding in "authenticated" HTTP requests into the pipeline.

I am a firm believer that this library should be as simple and intuitive as humanly possible. So I see 2 approaches for handling auth in the library.

One is in [[https://github.com//pull/15|PR #15]], which I initially was not thrilled with, but is starting to grow on me. It may not be the route we choose to take, but it is clearly named and well implemented. In this architecture, you have separate classes that only deal with authentication, each implementing IAuthenticator, as well as an "Authenticator" property on the RestClient. Then, at the beginning of each request, you call "Authenticator.Authenticate()". It would be up to that "Authenticate" method to determine if authentication is even necessary for that call, inject the proper headers into the request, etc.

The other I have in mind, which really only has subtle differences in implementation, but is closer to how you implement PortableRest for your APIs in the first place, would be to subclass RestClient. So you would have:

• BasicAuthRestClient
• OAuthRestClient
• JwtRestClient
• Etc.

In this pattern, the RestClient constructors would be different, allowing you to pass in ClientKey/ClientSecret in the case of OAuth & JWT, and the XXXRestClient would manage how it handles tokens, signatures, and other details inside that class itself. Then the class implementing the API (say if you are building Yet Another Twitter API) would change to inherit from OAuthRestClient, instead of just RestClient. That change would pick up all of the necessary functionality with no additional code.

Regarding how all that will be implemented, I have been working with the guys at Auth0.com to improve their libraries for dealing with JWT in the ASP.NET/OWIN pipeline. That code will include some extensions to turn JWT attributes into .NET claims, and that code could be leveraged in PortableRest too.

Because of that, some of the implementations will likely be add-on assemblies, because I do not want to have the core lib take a dependency on anything more than it already has to. So keep that in mind when you weigh in on which approach should be used.

At the end of the day, if you are building reusable REST APIs to post to NuGet and using PortableRest as the base, NONE of these options should surface to the developer that downloads that API off of NuGet and starts using it. Just like with my Xbox.Music client, the end developer should not have to deal with exoired tokens or anything else... the code implementing PortableRest should automatically handle that for you. So just keep that in mind as well.

Looking forward to your thoughts... - Robert

[ilmax]

Hi Robert,

when I developed the authentication support for PortableRest, I choose to use a separate interface IAuthenticator and a set of concrete implementations to provide Basic and NTLM authenticator because it was a very simple and clean way to implement authentication (read SRP), this gives you either the ability to use the same instance of the RestClient to perform requests over different resources with different authentication scheme just by swapping the Authenticator property on the RestClient instance (I don't know even if this make sense but flexibility is always a great thing to achieve).

Your approach is not bad either, the only request I made is the ability to have access to the authentication details on the derived classes, let say for example that I need to access a OAuth protected resource via REST
so, as soons as I get the token, I should be able to access and cache it until it expires.
So a bunch of virtual methods (read OCP) is greatly appreciated on base classes e.g OAuthRestClient, OpenIdRestClient and so on.

Regards, Max.