I've been intently looking at this article: http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server.
It seems that I got the authorization server to work because I'm able to obtain access and refresh tokens with the implicit, authorization code, resource owner credentials, and client credentials flows.
I'm having a problem with the resource server implementation as described in the article. I feel that there needs to be more settings on the resource server side that the article does not specify (does not even mention that there needs to be more settings provided that the article won't address). If I put the [Authorize] attribute on the Me controller, every request, even with a header Authorization: Bearer {{token here generated from the auth server}} will result in a 401.
I'm accustomed to writing a delegating handler to "intercept" requests before hitting up API controllers - which would look for the access token in the Authorization header, decrypt it, build a ClaimsIdentity off it, and save to Thread.CurrentPrincipal. I could then write an authorization handler that would practically decide whether the authorized user has the proper claims to access a specific API "action" or "function". But with OWIN, I think all this work has already been done, correct?
Currently, both the auth server and the resource server are running from the same machine, hosted by IIS. So, I figure that both servers are using the same machine keys for encryption/decryption.
Maybe I don't know the intricacies of the [Authorize] attribute and how it may (if it does) interact with OWIN middleware behind the scenes. If [Authorize] does depend on or interact with OWIN middleware, then I think I definitely need to specify some settings in Startup.Auth.cs beyond what the article states.
So again, what additional settings do I need to code in the resource server's Startup.Auth.cs to get the [Authorize] attribute to work?