OAuth/OpenID Connect sample with AD FS on server 2016
C# JavaScript HTML Other
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.nuget
Img
TodoHelpSPA
TodoHelpWeb
TodoListClient
TodoListService
TodoListWebApp
.gitattributes
.gitignore
CONTRIBUTING.md
LICENSE
README.md
WebApp-WebAPI-OpenIDConnect-DotNet.sln

README.md

Todo List Web

This is a sample that I built so that I could get more familiar with OpenID Connect, OAuth and how they are implemented with AD FS on Server 2016 TP5.

This sample is based on https://github.com/Azure-Samples/active-directory-dotnet-webapp-webapi-openidconnect

Todo List Web Contents

There are two projects in this solution: TodoListWebApp and TodoListService

  • TodoListWebapp: a web application where you can sign in and manage a personal todo List. There's also a page which shows you the claims for the ID Token and the API Access Token.
  • TodoListService: an API that stores the users their todo list.
  • TodoHelpWeb: a simple web application where you can sign in. I use this sample to demonstrate the AD FS 2016 capabilities of customizing the ID token.

Remarks:

  • REMARK #1: the todo list content is forgotten when the API is restarted. This is a simple educational example.
  • REMARK #1: the UserProfileController has not been touched/ported and has no use for the current state of the TodoListWeb application
  • REMARK #2: I'm not a developer. You can read, copy and use my code, but I'm not responsible for whatever happens. This sample is mainly focussed on understanding the nuances of OAuth/OpenIDConnect specifically with AD FS 2016. That's where I've put most of the effort (time) in. That also means there are probably several examples of how not to do MVC, or CSS or ... I'm always keen to learn and I appreciate feedback.

Additional Information

TodoListWebapp web.config:

TodoListService web.config:

TodoHelpWeb web.config:

AD FS Application Group Configuration:

Make sure to use the correct identifiers, keys and URL's as specified in the web.configs. You'll also need to configure the following Claim Issuance Rule for the API:

Transform an Incoming Claim:

  • Incoming claim type: UPN
  • Outgoing claim type: Name ID
  • Outgoing name ID format: unspecified

The API relies on this so that each todo list is only available to the user the list belongs too.

Some Screenshots

  • Landing page

Alt text

  • After signing in

Alt text

  • Manage to do list

Alt text

  • Show my claims

Alt text

Here you can see that for the Access Token I got a http://foo/bar "HardCodedValue" claim that was configured in the Claims Issuance Rules for the API. The name claim in the Access Token contains the sAMAccountName, but that was just a test. And the nameidentifier claims contains the UPN. The API relies on this claim to make sure todo lists are keyed off uniquely to each user.