1

I'm planning on distributing a binary package functioning much like the Dropbox/OneDrive/GoogleDrive windows apps. It's a client that communicates with a central API. It's really a machine to machine integration, but only certain users are allowed to configure it.

Therefore, I'm thinking of how to adress the setup, if there should be different clients in IdentityServer or not. Either way, there will only be certain users allowed to configure the client.

Alternative 1:

There is only one client registered in IdentityServer which all installations use. Authorized users (ICustomTokenRequestValidator) create a parameterized scope (in additional to offline_access) upon installation (http://docs.identityserver.io/en/latest/topics/resources.html#parameterized-scopes) which will then be included in the requested Access Token. The tokens are stored locally using e.g. https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.protecteddata?redirectedfrom=MSDN&view=net-5.0. The scope is translated to a claim denoting resource access/scope/tenant or the scope parameter could be used directly.

Alternative 2 (https://www.rfc-editor.org/rfc/rfc7591):

Clients are created by authorized users dynamically, e.g. by exposing an API in IdentityServer ( Is there a way to achieve Dynamic Client Registration with IdentityServer?). Allowed scopes are defined upon creation, and the client is configured using client credentials - like a true machine to machine integration. The endpoint is secured using a specialized authorization policy giving only certain users access.

I'm a little torn between the alternatives, both have pros and cons, but I'm favouring alternative 2 a little bit. This would not require any additinal plumbing such as ICustomTokenRequestValidator, IProfileService or IScopeParser, but would potentially flood the database with clients.

Both alternatives permit revoking compromised tokens, either by disabling the client (alt. 2) or calling the revoke endpoint.

My goal is to setup a secure client application in multiple locations while minimizing access and consequence if the access token is compromised.

Alternative 3:

This is not a dynamic client registration, but uses one client just like alternative 1. The API is configured using two scopes; one denoting the operation, e.g. https://api.myserver.com/op1, and a parameterized scope, e.g. tenant. The first scope is configured to include an additional claim denoting user_level (Authorization based on Scopes), which if the user has it, will be included in the access token. The API then checks for the existence of the operation scope, the parameterized scope and the user_level claim before giving access.

Is there any other alternative, or other considerations, pros and cons on the above alternatives?

Community
  • 1
  • 1
Vincent
  • 1,119
  • 11
  • 25

1 Answers1

0

I'm a little late to this question but we've learned a lot in our shop regarding these workflows recently.

In addition to replicated auth servers, most of the secure information exchanges (such as FHIR CURES-compliant APIs in the healthcare industry) seem to handle enrollment smoothest with your option#2. In fact, that's what we did in our shop for our healthcare software suite. It helps when you can do your own IOC interface implementation with Identity Server.

Proper coordination of how to best handle registration error objects/codes was pretty important if you have a heavy interface distribution list (otherwise if you run into a fair number of problems that don't match your use-case tests, your helpdesk could get inundated).

At the end of the day, you'll probably still want an option to be able to manually assign/review permission levels on a case-by-case basis, but it's nice to have a process in place that simplifies/automates as much as is possible, especially if the number of interfacing systems is large.

Of course, all of this assumes you don't have complete control over the client and server implementations. If you do have complete control (as in your shop built all participating software and owns all the data), then a simpler ActiveDirectory instance using Windows Authentication (or perhaps client-side certs) would make more sense IMHO.

MichaelBolton
  • 78
  • 2
  • 7