Looks promising.

Should be non-breaking for users that aren't explicitly using CAS (.NET libraries use it themselves) but it is probably important to have at least one user to validate the design (likely candidate is the auth-service.)

However, when using an expired token, the client is presented with {"title":"Authentication required","status":401,"detail":null}.

We are using:

<package id="D2L.Security.OAuth2" version="4.4.3.0" targetFramework="net452" />
<package id="D2L.Security.OAuth2.WebApi" version="3.3.1.0" targetFramework="net452" />

I've been reading the code and trying to puzzle out what is needed to get with working and I am flabergasted. I've tried to look at the test code and get it integrated with my StartUp.Auth.cs but I'm banging my head against the wall.

The OAuth2 specific stuff should be factored out of ID2LPrincipal so that we can make ID2LPrincipal more sanely injectible in non-OAuth2.0 cases.

The namespace is OAuth2 specific which is a bit weird but better to get the split right so that the eventual refactor will/would be easier.

We have a single error message for failures to look up a remote key. Something like: "remote key xyz at URL abc could not be found".
This covers the following problems if I remember correctly:

• Failure to resolve DNS
• Failure to connect (TCP)
• Failure to negotiate a TLS connection
• Failure to find the key (404)
• Key is expired

That last one burned us recently: a customer's key expired/wasn't rotated in time, and this lead to an outage for them. We worked from the bottom-up to diagnose this because we didn't notice that the exp timestamp on their key was old, and this delayed resolving the issue. If we had a more informative error message we could have resolved this much quicker.

Using DefaultRequestHeaders means that if an HttpClient is reused the tokens will get sent which is quite possibly undesirable.

• Remove System.Web.HttpMessage overloads
• Switch from other serialization stuff to Newtonsoft.Json
• Switch from System.Runtime.Caching to Microsoft.Framework.Caching.Memory for MemoryCache (possible breaking API changes?)
• The type or namespace name AsymmetricSignature(De)formatter could not be found [OS: #36]
• Possible SecurityKey/SecurityToken breaking API changes [OS: #36]
• Where are JwtSecurityToken and JwtSecurityTokenHandler
• D2LSecurityToken does not implement inherited abstract member SecurityToken.SigningKey.get [OS: #36]
• Bring in DNX version of D2L.Services.Core.Extensions.
• Build/bring in DNX version of D2L.Services.Core.Exceptions
• Figure out Newtonsoft.Json
• Netstandard D2L.CodeStyle.Annotations (Brightspace/D2L.CodeStyle#457) [OS: https://github.com//pull/109]

Need to be careful of internal migration

I guessed the version number incorrectly :(

This repo contains these NuGet packages:

D2L.Security.OAuth2
D2L.Security.OAuth2.WebApi
D2L.Security.OAuth2.TestFramework

They are currently versioned independently.

I think it'd make sense for them to be versioned in lock-step because these libraries are highly coupled (by design - the second ones are extensions) so it is confusing to keep track of compatibility versions of each currently.

It would also have some nice advantages for development: you can put all csproj into the same sln and use solution references instead of bringing them in as NuGet packages (what D2L.Security.OAuth2.WebApi has always had to do with D2L.Security.OAuth2.) Right now the feedback loop from change in core -> changes in WebApi is really annoying.

I think this would be a good general approach for the "core library + extensions" pattern.

Thoughts? @omsmith @brian-pearson @mpharoah-d2l

P.S.

The WebApi repo was merged into this one to make dev easier.

It matches the style of what MS is doing with .NET Core stuff (e.g. EntityFramework is many packages but one repo.)

AppVeyor CI also handles multiple-package case just swell.

https://github.com/Brightspace/D2L.Security.OAuth2/blob/master/src/D2L.Security.OAuth2/Keys/Default/ExpiringPublicKeyDataProvider.cs#L82

Currently the order to authorization attributes matters and may change the response body or code.
#51 provides one method of "solving" this, but probably not done particularly well.

We should do it better than that.

If a controller / route(?) is marked with [Authentication( users: true )], but a service-level token is provided, the client is presented with `{"Message":"Authorization has been denied for this request."} in the response.

(Not sure if there are any security concerns with explaining why).

Versions used:

<package id="D2L.Security.OAuth2" version="4.4.3.0" targetFramework="net452" />
<package id="D2L.Security.OAuth2.WebApi" version="3.3.1.0" targetFramework="net452" />

Future TODO: JsonWebKeyTests could do with some negative test cases.

Originally posted by @omsmith in #120 (comment)

Blocked on #6

See #110

We should be fine with just these test assemblies:

D2L.Security.OAuth2.UnitTests
D2L.Security.OAuth2.IntegrationTests
D2L.Security.OAuth2.Benchmarks