This project has moved and is read-only. For the latest updates, please go here.

OAuthAuthorizationServerHandler and Form Post response mode.

Jun 14, 2014 at 12:00 PM
Edited Jun 14, 2014 at 12:07 PM
Original thread:

I've played intensively with the new bits since they have been published and so far, OAuthAuthorizationServerHandler and OpenidConnectAuthenticationHandler seem to cohabit nicely thanks to your new extension points.

That said, I wonder if we could ameliorate the form post response mode implementation. As stated in your first post, it's currently left as an exercise for the end developer, who can for instance implement it using a high level framework like ASP.NET MVC or Nancy or write a little middleware/handler to print a simple form. But in both cases, the authorization server must redirect the user to the form page's endpoint with the required parameters in the query string (redirect_uri, id_token, code, etc.).

Sadly, this almost defeats the whole purpose of FPRM as you still have to flow these parameters in the query string where they can exceed the classical URL limits: this way, it won't work properly with large payloads.

It would be rather easy to directly write the form in the response stream instead of redirecting the browser first, but there's a major issue: ApplyResponseGrantAsync - where the FPRM is currently located - can either be called by the AuthenticationMiddleware class or from a OnSendingHeaders callback, which is really really bad as we're not supposed/allowed to write in the response stream from there.

I discussed with @Tratcher to find a solution, but nothing came up yet. If you have an idea, don't hesitate!

To be honest, I've been waiting for this discussion, since I published the pull request. You are right: There is room for improvement when it comes to passing the parameters to the page that does the FPRM. Using URL-Parameters was the most easy thing for me, but if I had a choice, I would use some kind of request-scope for it. I'm thinking about something like the following pseudo-code, which would work in ASP.NET "Classic":

// Middleware
Request.Item["params"] = params; // Put params (id_token, code etc.) into "request scope"
Server.Transfer("..."); // server-side "Redirect"

// Custom FPRM-Page
params = Request.Item["params"];

But as it seems, there isn't a thing like request scope or Server.Transfer in Katana/OWIN. Do you have an idea, how to simulate such things?

As I see it, we have the following options:

a) directly writing out the form and take care of OnSendingHeaders by setting a flag (both isn't the beautiest solution for me)
b) store the params (id_token, code, token etc.) somewhere and just pass an id/ a handle to this stored data when redirecting to the FPRM-page. This page could retrieve the data and delete it in the store.
b.1) We could use something like IAuthenticationTokenProvider, to map an id/ a handle to a dictionary with temp. parameters. Something like:
interface ITempParamsProvider {
 IDictionary<string, string> GetAndDeleteParams(string key);
 string SetParams(IDictionary params); // Returns key

What do you think?

I'm pretty sure we can use the OWIN environment dictionary and the Get/Set helpers on IOwinRequest/IOwinContext to flow the FPRM details through the pipeline (you can easily retrieve the OWIN context from ASP.NET/ASP.NET MVC using the HttpContext extensions in Microsoft.Owin.Host.SystemWeb or from Web API using the OWIN package) but indeed, I can't think of a Server.Transfer equivalent.

Writing the form in the response stream was my first idea, but having an intermediate store might be a great alternative. It wouldn't offer the "security bonus" offered by the real FPRM but would definitely resolve the payload size issue.