New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use opaque access tokens by default and update the MVC sample to use the new validation middleware #185

Closed
PinpointTownes opened this Issue Nov 30, 2015 · 6 comments

Comments

2 participants
@PinpointTownes
Member

PinpointTownes commented Nov 30, 2015

Starting with ASOS beta5, we'll stop using JWT as the default format for access tokens and go back to opaque tokens (serialized by the data protection block), exactly like OAuthAuthorizationServerMiddleware. Of course, JWT tokens will still be supported (using options.AccessTokenHandler = new JwtSecurityTokenHandler();), but will no longer be enabled by default (opting for JWT tokens for specific clients only will also be supported).

Since ASP.NET 5 offers no native support for opaque tokens, I developed 2 new middleware:

  • An introspection middleware: as the name suggests, this middleware will use ASOS' introspection/validation endpoint to determine whether an access token is still valid and retrieve the corresponding authentication ticket. To avoid flooding the introspection endpoint, this middleware comes with native distributed/local caching support. Though primarily designed to work with ASOS, it can be used with virtually any OAuth2 server supporting the introspection RFC. Using this middleware is recommended if the resource server(s) is/are not in the same application as the authorization server.
  • A validation middleware: this middleware is far simpler (and more efficient) than the introspection middleware as it directly decrypts the access token using the data protection block, instead of making an HTTP call to the authorization server. This middleware offers a much easier experience compared to JwtBearerMiddleware and OAuthIntrospectionMiddleware as it doesn't need any configuration by default but will only work if the resource servers and the authorization servers are part of the same application or share the same data protection keys. Of course, this middleware is only designed to support the opaque tokens produced by the data protection block and doesn't natively support JWT tokens. For such tokens, JwtBearerMiddleware is still the best choice.

The MVC sample will be updated to reflect those changes.

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes Dec 2, 2015

Member

OAuthIntrospectionMiddleware and OAuthValidationMiddleware have been backported to OWIN/Katana: https://github.com/aspnet-contrib/AspNet.Security.OAuth.Extensions/tree/dev

Member

PinpointTownes commented Dec 2, 2015

OAuthIntrospectionMiddleware and OAuthValidationMiddleware have been backported to OWIN/Katana: https://github.com/aspnet-contrib/AspNet.Security.OAuth.Extensions/tree/dev

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes Dec 3, 2015

Member

@louislewis2 please ping me on JabbR when you have a minute, I'd like to ensure the new validation middleware works with your zero-conf scenario 👏

Member

PinpointTownes commented Dec 3, 2015

@louislewis2 please ping me on JabbR when you have a minute, I'd like to ensure the new validation middleware works with your zero-conf scenario 👏

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes Dec 15, 2015

Member

Done (for 4 days now 😄).

ASP.NET 5: 939067d
OWIN/Katana: 5f3ba52

Member

PinpointTownes commented Dec 15, 2015

Done (for 4 days now 😄).

ASP.NET 5: 939067d
OWIN/Katana: 5f3ba52

@singlewind

This comment has been minimized.

Show comment
Hide comment
@singlewind

singlewind Dec 21, 2015

Great job. @PinpointTownes Forgive my ignorance, to replace with opaque tokens to replace JWT token as 1st choice option, is this something you consider more generic as an API or a more secure option?

singlewind commented Dec 21, 2015

Great job. @PinpointTownes Forgive my ignorance, to replace with opaque tokens to replace JWT token as 1st choice option, is this something you consider more generic as an API or a more secure option?

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes Dec 21, 2015

Member

Opaque tokens are actually the best compromise between security (as they are fully encrypted) and simplicity, because you don't have to configure anything to use them (as long as the authorization server and the resource server are part of the same application and share the same data protection keys, which should cover most basic cases).

This is particularly true with the validation middleware (aka the zero-conf middleware 😄), that doesn't require an audience by default, unlike the JWT bearer middleware.

One could argue that we could achieve the same security objective by using JWE (that should be supported by IdentityModel soon). It's true, but JWE token encryption comes with a downside: you have to manage a list of public keys corresponding to the resource servers (when using asymmetric keys) or share a symmetric key between the authorization server and the resource servers, which requires some advanced configuration, incompatible with the simplicity-by-default approach (that said, this is definitely something we'll support when JWE is implemented, it just won't be the default format).

Member

PinpointTownes commented Dec 21, 2015

Opaque tokens are actually the best compromise between security (as they are fully encrypted) and simplicity, because you don't have to configure anything to use them (as long as the authorization server and the resource server are part of the same application and share the same data protection keys, which should cover most basic cases).

This is particularly true with the validation middleware (aka the zero-conf middleware 😄), that doesn't require an audience by default, unlike the JWT bearer middleware.

One could argue that we could achieve the same security objective by using JWE (that should be supported by IdentityModel soon). It's true, but JWE token encryption comes with a downside: you have to manage a list of public keys corresponding to the resource servers (when using asymmetric keys) or share a symmetric key between the authorization server and the resource servers, which requires some advanced configuration, incompatible with the simplicity-by-default approach (that said, this is definitely something we'll support when JWE is implemented, it just won't be the default format).

@PinpointTownes

This comment has been minimized.

Show comment
Hide comment
@PinpointTownes

PinpointTownes Dec 21, 2015

Member

Oh and it has another merit: since we now have our own validation and introspection middleware, we no longer depend on the goodwill of the ASP.NET team... 😄

Member

PinpointTownes commented Dec 21, 2015

Oh and it has another merit: since we now have our own validation and introspection middleware, we no longer depend on the goodwill of the ASP.NET team... 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment