Split Microsoft.Owin.Security.Cookies.Interop into 2 packages

[kevinchalet]

We'd like to use the ticket serializer and the data protector adapter in the OWIN/Katana version of ASOS, but having a dependency on the cookies middleware is something we'd like to avoid. Separating the cookies extension from the rest of the package would be ideal.

#408 (comment)

aspnet-contrib/AspNet.Security.OpenIdConnect.Server#188 (comment)

If you agreed with the general idea, I (or @MonkeyJamboree) would be happy to submit a PR. I guess simply creating a new Microsoft.Owin.Security.Interop package containing the ticket serializer and the data protector would be the best way to go.

/cc @Eilon @HaoK @Tratcher

[Eilon]

We are not planning on doing this; we recommend just copying the code as needed.

[kevinchalet]

TBH, this doesn't seem to be a good idea, as the ticket serializer adapter must exactly match the one used by ASP.NET 5, which is an easy task when using an official package but rather fragile when rolling your own version.

[kevinchalet]

@Eilon if you don't like the idea of having a new package, maybe we could simply make the new Microsoft.Owin.Security.Interop a sources package?

[MonkeyJamboree]

@Eilon out of curiosity, why is copying the code recommended over actually separating out Microsoft.Owin.Security.Interop into its own package? It seems to me since the namespace and code is assumed to be for interoperability, it should be consumable by others easily. If not, is there a package that's explicitly for this purpose instead? Creating unneeded dependencies in code or duplicating code are usually are not good things.

[Tratcher]

This package was built specifically for interop with Microsoft.Owin.Security.Cookies.

One way to pull the src is via git submodule.

[kevinchalet]

This package was built specifically for interop with Microsoft.Owin.Security.Cookies.

True, but the ticket serializer and the data protector shim are not specific to the cookies middleware. Sounds like a bad layering IMHO.

[blowdart]

The ticket serializer was for Forms auth. Which became cookie auth, Arguably it is for the cookie middleware.

Data Protection has a 4.5.2 implementation which you can bring in as a normal nuget package.

[kevinchalet]

The ticket serializer was for Forms auth. Which became cookie auth, Arguably it is for the cookie middleware.

That would be a valid argument if the ticket serializer was not HEAVILY used by Katana's OAuth2 middleware...

[blowdart]

It's not any more though is it? And the interop package itself wasn't for OAuth either. It was designed for forms authentication, nothing more.

[kevinchalet]

It's not any more though is it?

Of course, since there's no OAuth2 middleware in vNext
But people (like me) might want to use the new ticket serialization format and the new data protection stack with Katana's authorization server.

There's absolutely no difference between cookies and access tokens as they use the same exact serialization format (which explains why the OAuth2 authorization server/bearer middleware and the cookies middleware share the same TicketDataFormat). You're just introducing an artificial distinction.

[kevinchalet]

So, wouldn't a new Microsoft.Owin.Security.Interop sources package be a good compromise?

[ryanwischkaemper]

+1

[DovydasNavickas]

+1
Yeah, that'd be great. And I really don't see any logical arguments why not... I understand you don't want to support multiple packages, but essentially it's splitting same code that you have. Not much of a difference for you, a whole lots of benefits for us.

[kevinchalet]

No Christmas gift for us? 😄