Consider aligning the ticket data format between the OWIN/Katana and ASP.NET 5 versions

[kevinchalet]

Because the two versions use different ticket formats and don't rely on the same data protection block, the tokens are not interoperable. We should determine ASAP if the formats should be re-aligned.

The ideal plan would be to use AspNetTicketSerializer from the new Microsoft.Owin.Security.Cookies.Interop package (https://github.com/aspnet/Security/blob/dev/src/Microsoft.Owin.Security.Cookies.Interop/AspNetTicketSerializer.cs) and the new data protection block.

Sadly, these options come with 2 downsides: they both require .NET 4.5.1 and the data protection block no longer uses web.config to configure keys storage.

/cc @MonkeyJamboree @marc-mueller @ilmax

[MonkeyJamboree]

I'm not sure I like the idea of relying on the Cookie middleware for ticket serialization as that adds a dependency, though I do agree that the same data protection block should be used.

I don't see the .NET 4.5.1 requirement as being too bad, honestly. It's been around long enough and has enough benefit that consumers should probably be moving to (at least) that version anyway, though that's admittedly a bit of a strong assumption on my part.

For cookies, not having the ability to configure key storage kind of makes sense since they're typically tied to the application in question for security purposes, though it does cause some issues in the realm of distributed applications or load balancers. The ability to configure keys storage is definitely something that would be a bonus in these areas. Another consideration is if resource servers themselves (that are on different boxes than the authorization server) would need to deserialize access tokens coming in instead of using the introspection endpoint.

At one point I made an AES ticket serializer that allowed you to pass it a key, but it was a quite hacky solution and I didn't like how it turned out. Other thoughts on options to solve this?

[kevinchalet]

I'm not sure I like the idea of relying on the Cookie middleware for ticket serialization as that adds a dependency, though I do agree that the same data protection block should be used.

When reviewing the PR adding the interop package, I suggested separating the cookies extension from the data protector/ticket serializer: aspnet/Security#408 (comment)

I'm pretty sure they would accept a PR separating the two things. Would you be interested in submitting a PR to aspnet/Security?

Another consideration is if resource servers themselves (that are on different boxes than the authorization server) would need to deserialize access tokens coming in instead of using the introspection endpoint.

Yes, being able to mix OWIN/Katana authorization servers/resource servers and vNext authorization servers/resource servers is the main objective of this ticket.

At one point I made an AES ticket serializer that allowed you to pass it a key, but it was a quite hacky solution and I didn't like how it turned out. Other thoughts on options to solve this?

Yes, a custom ticket serializer is an option. But you have to be extremely careful when building your own crypto stuff. The 2 or 3 implementations I've seen so far were all susceptible to specific crypto attacks (this one, for instance, doesn't correctly implement authenticated encryption and is vulnerable to timing attacks: https://github.com/i4004/Owin.Security.AesDataProtectorProvider/blob/master/Owin.Security.AesDataProtectorProvider/AesDataProtector.cs#L84). Using a rock solid library like the new data protection block is really my favorite option.

[MonkeyJamboree]

I'm pretty sure they would accept a PR separating the two things. Would you be interested in submitting a PR to aspnet/Security?

If I get a minute to look at it, perhaps, but I haven't even had time lately to work on some of the things I had been trying to work on for ASOS (namely, the dynamic registration stuff).

Using a rock solid library like the new data protection block is really my favorite option.

I agree with this 100% because then it is all in-line with what exists, and frankly rolling your own is a Bad Thing(tm).