2

I am working on implementing an authentication server which will provide single-sign-on for the web applications our company produces and am working with DotNetOpenAuth2 at the moment. My problem is that DNOA works like this (from the Apress book Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan)

DotNetOpenAuth Protocol

But I want it to work like so (this image I edited):

enter image description here

Is there a way to make it do this, or another framework I should use instead? I want to do this to make the security simpler and more comprehendable to later developers. Following is an explanation of why this would be a good fit for my purposes.

All of our web apps support HTTPS and are under 1 of 2 parent domains (so each web server has 2 x509 certificates that support SSL on subdomains like *.domain1.com or *.domain2.com).

My plan is to use the existing certificates as an implicitly shared secret to encrypt tokens minted by DotNetOpenAuth2. So when creating tokens the AuthorizationServerAccessToken.ResourceServerEncryptionKey would be the public key of the SSL cert and the AuthorizationServerAccessToken.AccessTokenSigningKey would be the private key of the SSL cert.

This way any of my servers has the ability to decrypt a user token and extract authorization claims from it in a secure way. Given the simplicity of the scheme I just want a single auth endpoint that receives a username and password and returns an encrypted token.

It seems this simplification makes things both more secure and easier to implement. Especially since we can do away with the nonce. One possible weakness is that an attacker that gains access to a web cert private key will also be able to spoof user auth tokens. But it seems that assuming your SSL certs haven't been compromised is ok security practice, given that the security of web applications usually rests entirely on that assumption. And I'm not storing sensitive information in the tokens anyways, just permission flags.

Ian
  • 4,169
  • 3
  • 37
  • 62

2 Answers2

1

The primary purpose of your diagram seems to be to cut out the authorization code exchange steps and just deliver the access token. Here's a related post I recommend reading to convince yourself of this step's usefulness. Also, do you really want to create your own OAuth2.0-like authorization protocol just because OAuth2.0 is confusing? I think as more developers adopt OAuth2.0, the concepts will start to feel less foreign.

Community
  • 1
  • 1
Mitch Stewart
  • 1,253
  • 10
  • 12
  • Read that post and I don't think it applies to my situation. If I understand it correctly, this flow is so that my application server (RP) can use a temp code to directly request a token from the STS using HTTPS for the cases in which my app is running HTTP and its not safe for the browser to post the token to my app. I intend to keep the token as a black box (encrypted and signed) on the client and use it as an authentication method across multiple apps/services. Also all my apps are running HTTPS. – Ian May 03 '17 at 22:00
1

I highly, highly recommend IdentityServer for what you're looking for. I'm on the verge of building an IdentityServer for my company as well, and after some initial playing around with it have found it to be the best "roll your own" solution. The other nice part is that the Authentication is decoupled from the Authorization, allowing you to swap out Identity Providers in the future (for example if you wanted to change Tenant IDs down the road) or add multiple Azure AD Tenants.

Also, you'll have much better control over the claims you want to pass back to users or daemons.

Kevin R.
  • 3,571
  • 1
  • 19
  • 29
  • Alright, we'll try framework #3 now. I'm assuming it has methods to encrypt and sign a JWT. – Ian May 03 '17 at 22:03
  • As far as I know. I've been mostly playing with IdentityServer4, which handles JWT encryption/decryption but I'm pretty sure v3 has the same abilities in that manner. The documentation I've found is extremely detailed. Best of luck. – Kevin R. May 03 '17 at 22:10
  • Oh no. I'll use v4, I just meant its the 3rd framework I'll be trying out after checking out Thinktecture's ID Server and DotNetOpenAuth. – Ian May 03 '17 at 22:16
  • Ah... There is a little bit of overhead, but it seems worth it. Aside from the docs on the website, I found this blog helpful also: https://www.scottbrady91.com/Identity-Server/Getting-Started-with-IdentityServer-4 – Kevin R. May 03 '17 at 22:18
  • At the end of the day even Identity Server didn't really fit what I wanted to do, which is really just single-sign-on. It was simpler to just roll my own token and use symmetric encryption across my servers (which can all share the symmetric key). – Ian Mar 29 '18 at 16:49