@hsakarp: Well I didn't cover filters :) AuthorizeActionFilters are at a deep level. Frankly we hope with the new policy based stuff you won't ever need to write one, but they're there, in case you want to do something really odd.
@figuerres:Yea, our previous attempts were sadly lacking, so come ASP.NET Core we decided to reinvest dev resources elsewhere as, frankly, Identity Server did everything better than our previous attempts. So don't expect an OAuth Server from our team any time soon.
@Ron Osmo:The next section will cover writing policy handlers. Hopefully it will address your questions, but yes, it's basically code that returns Succeed. Or nothing. Or fail. The video will make it clearer.
If you need something more configurable wait for RC2 when you can write your own policy provider, you get the policy name and return a policy configured as you want, so that would support client configuration.
As for claims and 3rd party auth, it depends on the 3rd party. The vast majority will, but you're dipping into authentication at this point. Facebook has a concept of scopes, but once you have logged in you would get an access token back which you can use to walk their graph API to get more details. Of course the user can simply refuse to grant you those permissions, they are in control. Google and Azure AD act in much the same way. If you had an identity service provider which fire fighters logged in through it may in turn give you their certifications and roles as claims.
As for mobile apps, well, not really. How it tends to work is the mobile app does an authentication dance, and then gets a bearer token, which you send with every request. Or the mobile app goes through your web site, which then prompts the oauth dance, your web site gets the tokens and identity back, and then your web site gives your mobile app an identity token, which you marry up on the back end to the identity returned from the oauth login.
@alexchesser01: Now you're dipping into authentication really. Which wasn't my area *grin*
I will say the cookies are encrypted and signed with a key generated by asp.net, which rotates (see the Data Protection documentation). So that can be trusted. Now, caching is really application dependent. Some folks don't care, others do. We can't really make that decision for you.
For REST you ought to be moving to bearer, as it removes CSRF vulnerabilities. The standard approach is JWT and we provide middleware to validate it, but nothing to issue, as again, that depends on your app and situation. We recommend IdentityServer for that, or Azure AD
@Genesis1:The authorization handlers support DI. So in the construction you'd take an instance of your repository for your rules data, then check it during handle. You'd still have authorize atributes in your controller with hard coded policy names.
If that's not flexible enough in RC2 you'll be able to change everything with a policy provider. We'll give you the name of the policy from the attribute and you can build the policy on the fly, adding and removing requirements as you see fit.