Let’s look at building our own OAUTH2 authorization server – using the software components provided by Microsoft to dotNet developers (running on windows, or in open source mono stacks). Recall that when we did this last year, we simply delegated most of the work to the ACS in Azure). Though what follows clearly show how to wrap-up such ACS capabilities now “properly, it also shows how one can specialize the capability in other ways.
Creating an OAUTH2 authorization server using the Katana implement of the OWIN conventions allows us to issue an access token – a serialization of a claimsIdentity value. This is really easy (once you know how, of course). One creates a webapi tuned up by behaviour insertion to act as the desired authorization server, exposing authorization and token endpoints.
An appropriate metaphor for the workings of an authorization server is just the theatre “will call”, world of ticketing a show: you call ahead to the box office and pay for the ticket that you WILL CALL at the box office for, later (given a onetime code given to you on the phone, after paying). It’s will-call!
Of course, the box office doesn’t limit folks to only will-call modes of getting tickets and thus access to the show. It also offers swapping of vouchers (another theatre’s ombinbus tickets are good here, on a “visit 3 shows in a week tourist package”) , turning up and just paying (resourceownergrant), or corporate sponsorship (clientcredentialsgrant) that comes with 1 box and 10 gallery seats.
You customize the generic authorization server implementation by assigning callback methods. These react suitably to such as clientCredentials grant-seeking client – presenting the “corporate sponsorship” id/password. To customize these server-side behaviors one assign those callbacks that check the sponsorship-specific passwords; and then issue sponsorship-class-ticket good for presentation at the “sponsors’ entrance to the theatre. When issuing other ticket classes good at the public entrance, there are other variations of the callbacks. One interesting class is the “renewal” ticket, that allows one to get a pass to the second half, having previous got a pass only to the first half. It may then allow allow one to get a pass to the after-show, all using the common “renewable” ticket
To mint different types of tickets (known generally as access tokens) we see insertion of a C# formatter class – that can format (and protect) the serialized tickets. Other ways of specializing the ticket-minting apparatus, for variation on the themes above, include
- The means used to delegate to others how one obtains and validates access tokens (which might mean use delegate all the work, expressed in callbacks, to the ACS oauth API!)
- The means to handle refresh tokens (perhaps done different to access tokens, should ACS not support the concept)
- And the means to validate the vendor or resource-owners credentials, when responding to those grant types.