Apr 06, 2018 01:44 PM|noJedi|LINK
I can't find much in the way of current consistent reliable working information on this, coupled with I'm not sure where exactly is the right place to post this kind of thing, but here goes anyway.
I have a web app with MVC, Identity and any number of external auth (google, twitter, etc), logging into the site with defaultScheme as "cookie" is fine and works appropriately.
not quite GROKing something...
everything I have is working individually as expected (or as per any number of workings based on many blogs and tutorials, however:
If I setup "cookies" as the defaultScheme then I can use the local login (or google or whatever) to get "authentication" and a ClaimsPrincipal and sub identity, this also allows access to the API, as the "cookie" identity works also.... however trying to
access the API via a request via POSTMAN (or just anothr app using "clientcredentials") results in a request unauthorized (401? I think) and removing the "authorize" attribute and looking at the User on these requests reveals that the "ClaimsPrincipal" is
"empty" and "IsAuthenticated" is false.
The opposite is true if I set either "Bearer" as the defaultScheme, or use the "Authorize" attribute like so [Authorize(AuthenticationScheme="Bearer")]
So given all this (and hopefully the bug to do with merging authorize attributes (?https://github.com/aspnet/Mvc/pull/7129? not sure what is the actual "root" but HaoK is involved and the example is around
Dec2017) in Aspnetcore that may or may not be fixed has nothing to do with my specific issue? ) what am I doing wrong/is wrong with my expectations?
Is the intent NOT to use both and just go with tokens for all API access "the end"
Is there a way to get "fall back" authentication working? eg: set "bearer" as the default but fall back to cookies if we are in the browser?
other? some approach that I'm missing...
TBH, I am not convinced that I really understand the difference between: