Tokens should be constrainable to individual tenants

[jnschaeffer]

As described in the fertilesoil document on identity, subject identities should always be constrained to some tenant context to facilitate better access control and auditing logic. identity-manager-sts does not currently support this. However, RFC 8693 supports the use of audience and resource parameters for logical service names and URIs respectively, and we can leverage those to constrain a token to a given tenant. This implies that the STS supports some kind of binding between tenant nodes and individual issuers.

A few questions come from this:

• What does the management API for this flow look like?
• What makes more sense: audience (logical tenant name) or resource (tenant URI)?
• Do we want to support issuing tokens that are valid for multiple tenants?

Ultimately a solution should preferably leverage existing RFCs rather than relying on custom claims or other such logic.

[jnschaeffer]

As part of #40, we are going to use resource to scope access tokens to services/APIs, as the resource parameter is designed to map to the aud claim in RFC 9068 access tokens.