What this means is that the project is really two: an authorization server (doing something like the oauth protocol, in pattern terms) and a webAPI. The components doing each function are all jumbled together in the source tree.
One sees an accountcontrollee implementing the guts of the oauth endpoints, and the new ASP.NET libraries helping the authorize endpoint challenge users (and validate credentials using a db of challenge evidence). one also sees in the webAPI the mechanism used to introduce an bearer interceptor into the pipeline, that can do the oauth dance with what we just described .. when no bearer token is recovered from the HTTP request.
Fortunately, an article helps out! See http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
In short, we will use Fiddler to pretend that we have built the “missing” link – a third project that one can think of as the missing windows store app, the windows phone app, or a azure mobile site’s app, etc.
Our having updated libraries to use pre-release builds probably explains why we get the following error:
So let’s add an Email Address to the registration information. Let’s also change the password, since later one would also get “Passwords must have at least one non letter or digit character. Passwords must have at least one uppercase (‘A’-‘Z’).”
Getting back to the article: we now do NOT use the authorize phase of the OAUTH handshake moving straight onto what is normally phase #2: token swapping. So, we provide one token (the uid/pwd) and seek to get back another (a JWT) asking the engine to be a swapper – since that’s want the grant type of ‘password’ does. Complicated OAUTH formalisms about that also exist, if you want to confuse yourself.
but the token method doesn’t work (and no accountcontroller method exists); whereas method do exist for “external” sources of login event. its almost as if the internal authorization functionality was removed.
So let’s abandon THAT article and go with the flow, now figuring on using external authentication. Presumably, all the fabric left in accountcontroller and asp.net Identitymodel exist to do account linking (of that yet to be obtained token from an external provider). Perhaps, yet, post account linking our own code will mint a “local” bearer token. Lets see!
First, we just do the obvious:
but it doesn’t do anything. So what gives?
Somehow we cannot talk to Token and we cannot redirect to our external source. lets asume that all such logic is supposed to be in the webapi consumer.