Most published WebAPI samples (e.g. http://msdn.microsoft.com/en-us/library/azure/dn646737.aspx) are based on the MVC and OWin infrastructure, which is not available in WebForms applications. Following is a custom implementation of an OAuth2 access token handler presented by a WPF rich client application. The WPF is responsible for managing the OAuth code grant flow to obtain the token and present it to the WebForms application as part of an HTTP call. The code is based on the above samples but modified to support WebForms.
Features:
- The WebForm application is registered in an Azure AD as a multi-tenant web application. It's application manifest is modified as per sample instructions (see for example https://github.com/AzureADSamples/NativeClient-WebAPI-MultiTenant-WindowsStore, item 15 under the Register ToDoListServiceMT section).
- To client, WPF application is registered in Azure AD as a native application. It is multi-tenant by default.
- The WebForms application extracts and validates the OAuth2 access token (in JWT format) in the JWTTokenValidator class. The class is also responsible for retrieving current federation metadata from the Azure AD tenant in which the ASP.NET application is defined to obtain the owning issuer id and token signing keys.
- Once validated, JWTTokenValidator sets the appropriate ClaimsPrincipal on the current thread.
- The WebForms application supports adding new tenants either through a set of web pages (RequestConsent/ProcessConsent) or via a REST API called by the rich client. In the second case, the JWTTokenValidator needs to be modified to remove the initial check for token issuer: the signup API must allow the user to be authenticated even if the user is from an as yet un-signed-up tenant. Relevant lines of code are commented appropriately.
- The application is currently using an in-memory array of valid issuers, which obviously does not persist between runs. For production purposes it needs to be replaced by a persistent database.
Image may be NSFW.
Clik here to view.
