How to perform Sign-in with IdentityServer3?

Question

I am developing a web api for use with IdentityServer3.

I have the server and the web api running, but I am having trouble figuring out how to have users login from a mobile app to the server.

My question is this: if I have implicit flow enabled for the identity server, how do users sign in from a tool like fiddler to receive their tokens upon successful authentication?

I know that the token endpoint is:

https://myidservername/identity/connect/token

I also know that the authorization endpoing is: https://myidservername/identity/connect/authorization

But where do users sign in? Do I have to create my own view for users to be able to pass a username and password and receive a token? More specifically, my question is how to sign in from fiddler, not from a dedicated view that I would have to render to users.

Answer 1

IdentityServer is an all-in-one OpenID+OAuth 2 implementation, for this reason Implicit Flow is entirely handled by IdentityServer itself using the authorize endpoint as a bridge between an authentication request and the token issuing process.

The nature of Implicit Flow does not allow clients such as Fiddler (more precisely, clients that cannot render directly a web page) to authenticate. To further understand why I will try to reproduce the steps of OAuth Implicit grant in a Web API/IdentityServer scenario:

1. A client tries to access to a protected resource endpoint (e.g. a Web API controller decorated with Authorize)
2. The framework checks if the user is authenticated by validating the token (e.g. checking the Authorization header and validating its content)
3. If the user is not authenticated, the framework responds with a 401 status code
4. The client then must request a token to the Authorization Server (IdSrv3) by going to the authorize endpoint using a browser window (e.g. creating a WebView/UIWebView in a mobile app, opening a pop-up inside the browser, etc.)
5. The user then inserts his credentials, the auth server validates them and, if valid, responds with a redirect which includes an issued token inside the query string (or after the hash)
6. The client receives the redirect response and extracts the token from the URI
7. The client can now send authenticated requests to the resource server (Web API)

As you can see, you have no way to authenticate a client that cannot inherently render the login page returned in step 4. For those class of clients Resource Owner Credentials Flow may be a better solution.

You need to enable such grant for your client inside IdentityServer configuration (you may follow this tutorial to find out how), and then craft a request for the token endpoint setting grant_type to password and providing all other required parameters.