rethink POST /client

[spruce-bruce]

Description

The client POST endpoint is provided by our oidc library to allow clients to register with our service. Because of the nature of the way the synapse oidc platform is used, we currently have no near term expectation that anonymous client applications will ever want to access our system for the purpose of allowing users to authenticate.

Because we're building this platform with an assumption of trusting our client applications (because both the authentication service and the client application are controlled by the same party in all of our current use cases) we make assumptions that as long as a client is authenticated w/ client credentials that they have access to all user data.

SO - since we make that assumption - we must put up a barrier to entry to the POST /client endpoint to prevent anonymous people from gaining access to user data.

Proposed solution

Talked to @agerbens, @melissanoelle and @msinnes about approaches and landed on keeping the POST endpoint, but requiring some sort of approval by a trusted party (which I would implement as an approved boolean on the client table).

Alternatives

1. figuring out claims/scopes more in depth and only allowing clients access to users who have already granted permission
2. Disabling the POST endpoint either w/ env var configuration, or removing it all together.

Tasks

1. Add boolean active column to SIP_client table (make sure it can't be set by the client POST endpoint)
2. Make sure the client credentials auth strategy checks that the client is "active" before authenticating
3. Update README to say that you need to manually set "active" to true after creating a client by POSTing to op/reg

[spruce-bruce]

I'm an idiot and was wrong about the severity of this issue.

It's required to provide an "initial access token" to create a client (which i forgot about), so the POST client endpoint is not open to the world.

It's still probably worthwhile to leave this open and figure out what we want to do about the inadequacies of the initial access token, though.

[zpchavez]

Not really an issue, as described in https://github.com/synapsestudios/oidc-platform/issues/216#issuecomment-342576722

Anything about initial access token improvements should be a different issue

[bobeagan]

This needs to have the relevant information extracted and created into a new issue